等級保護測評策略建議整改措施

 

主機安全

 服務器windows

身份鑑別php

b)操做系統和數據庫系統管理用戶身份標識應具備不易被冒用的特色,口令應有複雜度要求並按期更換;mysql

整改方法:linux

修改配置策略:  
一、查看控制面板—管理工具—本地安全策略—帳戶策略—密碼策略;  
二、查看控制面板—管理工具—計算機管理—系統工具—本地用戶和組—用戶—右鍵—屬性—是否勾選「密碼永不過時」。  
建議修改值:  
(一)策略修改  
一、密碼必須符合複雜性要求;   已啓用  
二、密碼長度最小值;    12個字符  
三、密碼最長使用期限;   42天  
四、密碼最短使用期限;  2天  
五、強制密碼歷史;   5個記住密碼  
六、密碼永不過時屬性。  未勾選「密碼永不過時」 
(二)使用狀況  
口令長度至少12位以上,由數字、特殊字符、字母(區分大小寫)組成,每三個月按期進行修改
web

f)應採用兩種或兩種以上的組合的鑑別技術對管理用戶進行身份鑑別。sql

•     整改方法:數據庫

•     驗證檢查:  
一、採用令牌、USB-KEY或智能卡等身份認證技術手段對用戶進行身份鑑別  
建議整改:  
部署雙因素產品或者堡壘機
ubuntu

訪問控制windows

a)應啓用訪問控制功能,依據安全策略控制用戶對資源的訪問;centos

•     整改方法:安全

•     驗證檢查:  
是否能提供用戶權限對照表,設置的用戶權限是否與權限表一致。  
建議整改:  
完善用戶權限表(紙質版或電子版)

•     c)應實現操做系統和數據庫系統特權用戶的權限分離;

•     整改方法:

•     驗證檢查:  
一、詢問操做系統管理員與數據庫管理員是否爲同一人;  
二、檢查操做系統管理員與數據庫管理員是否使用不一樣的帳戶登陸。  
建議整改:  
一、操做系統管理員與數據庫管理員不爲同一人; 
二、操做系統管理員與數據庫管理員使用不一樣的帳戶登陸。

•     f)應對重要信息資源設置敏感標記;

•     整改方法:

•     驗證檢查:  
一、詢問主機管理員是否認義了主機中的重要信息資源;  
二、詢問主機管理員,是否爲主機內的重要信息設置敏感標記。  
建議整改:  
暫無

•     g)應依據安全策略嚴格控制用戶對有敏感標記重要信息資源的操做。

•     整改方法:

•     驗證檢查:  
一、詢問主機管理員是否認義了敏感標記資源的訪問策略;  
二、查看有敏感標記的重要信息資源是否依據訪問策略設置了嚴格的訪問權限。  
建議整改:  
暫無

安全審計

•     a)審計範圍應覆蓋到服務器上的每一個操做系統用戶和數據庫用戶;

•     b)審計內容應包括重要用戶行爲、系統資源的異常使用和重要系統命令的使用等系統內重要的安全相關事件;

•     d)應可以根據記錄數據進行分析,並生成審計報表;

•     F)應保護審計記錄,避免受到未預期的刪除、修改或覆蓋等。

•     總體考慮

•     整改方法:

•     驗證檢查:  
一、查看控制面板—管理工具—本地安全策略—本地策略—審覈策略;  
二、詢問並查看是否有第三方審計工具或系統。 
建議整改:  
(一)策略修改  
   一、審覈策略更改;   成功  
   二、審覈登陸事件;   成功,失敗  
   三、審覈對象訪問;   成功,失敗  
   四、審覈過程跟蹤;   成功,失敗  
   五、審覈目錄服務訪問;沒有定義  
   六、審覈特權使用;   成功,失敗  
   七、審覈系統事件;   成功  
   八、審覈帳戶登陸事件;   成功,失敗  
   九、審覈帳戶管理。   成功,失敗  
(二)windows自身日誌查看  
右鍵【個人電腦】/【此電腦】→【管理】→【事件查看器】→右鍵單擊任一事件查看器→Windows日誌,查看應用程序、安全、Setup、系統日誌的時間是否知足存儲6個月;同時點擊應用程序、安全、Setup、系統日誌右鍵【屬性】,審計日誌的存儲大小設置知足需求,但不得低於64M(默認是20M),達到最大日誌量後應選擇日誌滿時將其存檔,不覆蓋事件(默認是按須要覆蓋日誌(舊事件優先))  
(三)設備部署  
一、物理機房:部署日誌審計系統  
二、上雲服務器(如阿里雲):日誌服務

入侵防範

•     a)應可以檢測到對重要服務器進行入侵的行爲,可以記錄入侵的源IP、攻擊的類型、攻擊的目的、攻擊的時間

•     b)應可以對重要程序的完整性進行檢測,並在檢測到完整性受到破壞後具備恢復的措施;

•     c)操做系統應遵循最小安裝的原則,僅安裝須要的組件和應用程序,並經過設置升級服務器等方式保持系統補丁及時獲得更新。

•     總體考慮

•     整改方法:

•     驗證檢查:  
一、詢問是否安裝了主機入侵檢測系統,並進行適當的配置;  
二、查看是否對入侵檢測系統的特徵庫進行按期升級;  
三、查看是否在檢測到嚴重入侵事件時提供報警。 
四、詢問是否對關鍵程序的完整性進行校驗; 
五、管理工具—服務—查看可使用的服務  
六、監聽端口,命令行輸入「netstat -an」  
七、「控制面板」—「管理工具」—「計算機管理」—「共享文件夾」  
建議整改:  
(一)策略修改  
一、僅開啓須要的服務端口(135 137 139 445等端口建議不開啓,若業務須要,應作好系統相應補丁)  
二、關閉不須要的組件和應用程序,僅啓用必須的功能  
三、關閉默認共享文件  
(二)設備和服務部署  
一、物理機房:部署IDS、IPS  
二、上雲服務器(如阿里雲):部署安騎士或態勢感知、web應用防火牆、抗DDoS

惡意代碼防範

•     a)應安裝防惡意代碼軟件,並及時更新防惡意代碼軟件版本和惡意代碼庫;

•     b)主機防惡意代碼產品應具備與網絡防惡意代碼產品不一樣的惡意代碼庫;

•     c)應支持防惡意代碼軟件的統一管理。

•     總體考慮

•     整改方法:

•     驗證檢查:  
一、查看是否安裝了防惡意代碼軟件; 
二、查看惡意代碼庫是否爲最新;  
三、主機防病毒軟件是否與網絡版防病毒軟件相同 
四、安裝的防病毒軟件是否支持統一管理 
建議整改:  
(一)設備和服務部署  
一、物理機房:防病毒網關、包含防病毒模塊的多功能安全網關和網絡版防病毒系統,任選一種部署  
二、上雲服務器(如阿里雲):態勢感知或安騎士

資源控制

•     b)應根據安全策略設置登陸終端的操做超時鎖定;

•     整改方法:

•     驗證檢查:  
一、桌面右鍵—個性化—屏幕保護程序;  
二、在運行中輸入gpedit.msc打開「組策略」,在計算機配置—管理模塊—Windows組件—遠程桌面服務—遠程桌面會話主機—會話時間限制中,查看是否設置「活動但空閒的遠程桌面服務會話時間的限制」。  
建議整改:  
(一)策略修改  
一、啓用屏保並勾選「在恢復時顯示登陸屏幕」  
二、設置「活動但空閒的遠程桌面服務會話時間的限制」(推薦值設置15分左右)1.1.2. linux

身份鑑別

•     b)操做系統和數據庫系統管理用戶身份標識應具備不易被冒用的特色,口令應有複雜度要求並按期更換;

•     centos/Fedora/RHEL

•     整改方法:

•     驗證檢查:  
一、查看/etc/login.defs,訪談詢問當前所設置的密碼長度及更換週期;  
二、查看/etc/pam.d/system-auth,確認密碼複雜度要求。  
       密碼最長有效期PASS_MAX_DAYS;  
       密碼最短存留期PASS_MIN_DAYS;  
       密碼長度最小值PASS_MIN_LENS;  
       密碼有效期警告PASS_WARN_AEG;  
       密碼須包含大寫字母個數ucredit;  
       密碼須包含小寫字母個數lcredit;  
       密碼須包含的數字字符個數dcredit; 
       密碼須包含的特殊符號個數ocredit。 
建議整改:  
(一)策略修改  
一、/etc/login.defs文件中進行以下變量配置:  
PASS_MAX_DAYS:90;  
PASS_MIN_DAYS:2;  
PASS_MIN_LENS:8;  
PASS_WARN_AEG:7;  
二、/etc/pam.d/system-auth文件中添加下面信息:  
password requisite pam_cracklib.so minlen=8 ucredit=-1 lcredit=-1 dcredit=-1ocredit=-1;  
三、當前所設置的密碼長度應很多於8位,具備必定的複雜度並能按期更換。

•     Ubuntu/Debian

•     整改方法:

•     驗證檢查:  
一、查看/etc/login.defs,訪談詢問當前所設置的密碼長度及更換週期;  
二、查看/etc/pam.d/common-password,確認密碼複雜度要求。  
       密碼最長有效期PASS_MAX_DAYS;  
       密碼最短存留期PASS_MIN_DAYS;  
       密碼長度最小值PASS_MIN_LENS;  
       密碼有效期警告PASS_WARN_AEG;  
       密碼須包含大寫字母個數ucredit;  
       密碼須包含小寫字母個數lcredit;  
       密碼須包含的數字字符個數dcredit; 
       密碼須包含的特殊符號個數ocredit。 
建議整改:  
(一)策略修改  
一、/etc/login.defs文件中進行以下變量配置:  
PASS_MAX_DAYS:90;  
PASS_MIN_DAYS:2;  
PASS_MIN_LENS:8;  
PASS_WARN_AEG:7;  
二、/etc/pam.d/system-auth文件中添加下面信息:  
password requisite pam_cracklib.so minlen=8 ucredit=-1 lcredit=-1 dcredit=-1ocredit=-1;  
三、當前所設置的密碼長度應很多於8位,具備必定的複雜度並能按期更換。

•     c)應啓用登陸失敗處理功能,可採起結束會話、限制非法登陸次數和自動退出等措施;

•     整改方法:

•     驗證檢查:  
一、find /lib* -iname "pam_tally2.so"或find /lib* -iname "pam_tally.so"是否有改動態庫 
二、是否有如下參數:auth required pam_tally2.so  onerr=fail deny=X  unlock_time=Xeven_deny_root root_unlock_time=X(限制從終端登陸)  
三、/etc/pam.d/sshd文件中是否有以上相同參數(限制ssh登陸) 
建議整改:  
一、centos:/etc/pam.d/system-auth或Ubuntu:/etc/pam.d/common-password文件中添加:auth required pam_tally2.so onerr=fail  deny=3  unlock_time=40 even_deny_rootroot_unlock_time=30  
注意添加的位置,要寫在第一行,即#%PAM-1.0的下面。  
以上策略表示:普通賬戶和 root 的賬戶登陸連續 3 次失敗,就統一鎖定 40 秒, 40 秒後能夠解鎖。  
若是不想限制 root 賬戶,能夠把  even_deny_root root_unlock_time這兩個參數去掉, root_unlock_time 表示 root 賬戶的 鎖定時間,onerr=fail 表示連續失敗,deny=3,表示 超過3 次登陸失敗即鎖定。 
二、/etc/pam.d/sshd文件中添加相同參數  
(備註:以上參數根據實際狀況進行設置,至少配置/etc/pam.d/sshd文件限制ssh登陸)

•     f)應採用兩種或兩種以上組合的鑑別技術對管理用戶進行身份鑑別。

•     整改方法:

•     驗證檢查:  
操做系統登陸是否採用口令+令牌、USB KEY等方式進行身份鑑別。  
建議整改:  
(一)設備或服務部署  
一、物理機房:採用雙因子認證設備 
二、上雲服務器(如阿里雲):雲堡壘機

訪問控制

•     a)應啓用訪問控制功能,依據安全策略控制用戶對資源的訪問;

•     整改方法:

•     驗證檢查:  
是否能提供用戶權限對照表,設置的用戶權限是否與權限表一致。  
建議整改:  
完善用戶權限表(紙質版或電子版)

•     d)應嚴格限制默認賬戶的訪問權限,重命名系統默認賬戶,修改這些賬戶的默認口令;

•     整改方法:

•     驗證檢查:  
一、重命名系統默認賬戶(root);  
二、修改默認賬戶的口令。  
建議整改:  
一、根據業務需求狀況對root進行重命名,其口令必須進行修改

•     f)應對重要信息資源設置敏感標記;

•     整改方法:

•     驗證檢查:  
一、詢問主機管理員是否認義了主機中的重要信息資源;  
二、詢問主機管理員,是否爲主機內的重要信息設置敏感標記。  
建議整改:  
暫無

•     g)應依據安全策略嚴格控制用戶對有敏感標記重要信息資源的操做。

•     整改方法:

•     驗證檢查:  
一、詢問主機管理員是否認義了敏感標記資源的訪問策略;  
二、查看有敏感標記的重要信息資源是否依據訪問策略設置了嚴格的訪問權限。  
建議整改:  
暫無

備註:linux系統分爲Ubuntu、OpenSUSE、Fedora、Debian、RHEL、CentOS等,每一個系統又分爲不一樣的版本,所以在修改策略時須要在相同環境的測試機上進行驗證後,在正式環境中進行修改

 

安全審計

•     a)審計範圍應覆蓋到服務器上的每一個操做系統用戶和數據庫用戶;

•     b)審計內容應包括重要用戶行爲、系統資源的異常使用和重要系統命令的使用等系統內重要的安全相關事件;

•     c)審計記錄應包括事件的日期、時間、類型、主體標識、客體標識和結果等;

•     d)應可以根據記錄數據進行分析,並生成審計報表;

•     e)應保護審計進程,避免受到未預期的中斷;

•     f)應保護審計記錄,避免受到未預期的刪除、修改或覆蓋等。

•     總體分析

•     整改方法:

•     驗證檢查:  
一、輸入service syslog/rsyslog status 、service auditd status查看進程是否存在。  
二、(centos:cat /etc/syslog.conf或cat /etc/rsyslog.conf文件中應包含相似於如下值:*.info;mail.none;news.none;authpriv.none;cron.none/var/log/messages;)(Ubuntu:cat/etc/rsyslog.d/50-default.conf 文件中應包含相似於如下值:*.info;mail.none;news.none;authpriv.none;cron.none/var/log/messages;) 
三、是否對審計日誌按期查看、分析,生成審計分析報表  
四、是否安全額外的審計進程保護  
五、查看syslog.conf、audit.conf文件中日誌信息所在文件的訪問權限,如:  
 ls -l /var/log/messages;  
 (centos:ls -l/var/log/secure);(Ubuntu:ls -l/var/log/auth.log) 
 ls -l /var/log/audit/audit.log;   
訪談並詢問是否對審計日誌進行保護 
建議整改:  
(一)策略修改  
一、保障rsyslog和auditd進程開啓  
二、/etc/rsyslog.conf或/etc/rsyslog.d/50-default.conf文件中日誌配置以下:  
# 記錄全部日誌類型的info級別以及大於info級別的信息到/var/log/messages,可是mail郵件信息,authpriv驗證方面的信息和cron時間任務相關的信息除外  
*.info;mail.none;authpriv.none;cron.none                /var/log/messages    
# The authpriv file has restricted access. 
# authpriv驗證相關的全部信息存放在/var/log/secure  
authpriv.*                                             /var/log/secure    
# Log all the mail messages in one place. 
# 郵件的全部信息存放在/var/log/maillog; 這裏有一個-符號, 表示是使用異步的方式記錄, 由於日誌通常會比較大  
mail.*                                                 -/var/log/maillog    
# Log cron stuff  
# 計劃任務有關的信息存放在/var/log/cron  
cron.*                                                 /var/log/cron    
(備註:以上配置須要先在測試環境中驗證是否正確後,在正式環境中進行修改)  
三、ls -l /var/log/messages:640; ls -l /var/log/secure:640;   
ls -l /var/log/audit/audit.log:640;ls -l /var/log/auth.log 640;(備註:保持系統默認就行,惟一須要知足的就是普通用戶對這些文件只能有讀的權限)  
四、查看 /var/log/messages、/var/log/secure、/var/log/audit/audit.log、/var/log/auth.log日誌文件的內容是否被覆蓋和刪除,保存是否知足6個月  
(二)設備或服務部署  
一、物理機房:日誌服務器或日誌審計系統或堡壘機 
二、上雲服務器(如阿里雲):OSS或日誌服務或jumpserver 


入侵防範

•     a)應可以檢測到對重要服務器進行入侵的行爲,可以記錄入侵的源IP、攻擊的類型、攻擊的目的、攻擊的時間,並在發生嚴重入侵事件時提供報警;

•     整改方法:

•     驗證檢查:  
一、安裝主機入侵檢測系統並配置策略; 
二、按期對主機入侵檢測系統的特徵庫進行維護升級;   
三、發生嚴重入侵事件時提供報警。 
四、是否常常命令查看more /var/log/secure | grep  refused (centos)  
五、more /var/log/auth.log | grep  refused (ubuntu)  
六、是否啓用主機iptables防火牆規則、TCP SYN保護機制  
建議整改:  
(一)設備或服務部署  
一、物理機房:部署入侵檢測和防護系統(IDS、IPS或防火牆帶有入侵檢測和防護)  
二、上雲服務器(如阿里雲):安騎士或態勢感知或其它防入侵服務

•     c)操做系統應遵循最小安裝的原則,僅安裝須要的組件和應用程序,並經過設置升級服務器等方式保持系統補丁及時獲得更新。

•     整改方法:

•     驗證檢查:  
一、對系統補丁進行評估、測試後進行安裝 
二、系統遵循最小安裝原則  
建議整改:  
(一)策略修改  
一、如需最新補丁,須要評估、測試,或者根據業務使用穩定版本補丁  
二、關閉危險網絡服務:echo、login等,關閉非必要的網絡服務:talk、ntalk、sendmail等

 

惡意代碼防範

•     a)應安裝防惡意代碼軟件,並及時更新防惡意代碼軟件版本和惡意代碼庫;

•     b)主機防惡意代碼產品應具備與網絡防惡意代碼產品不一樣的惡意代碼庫;

•     c)應支持防惡意代碼軟件的統一管理。

•     總體考慮

•     整改方法:

•     驗證檢查:  
一、查看是否安裝了防惡意代碼軟件; 
二、查看惡意代碼庫是否爲最新;  
三、主機防病毒軟件是否與網絡版防病毒軟件相同 
四、安裝的防病毒軟件是否支持統一管理 
建議整改:  
(一)設備和服務部署  
一、物理機房:防病毒網關、包含防病毒模塊的多功能安全網關和網絡版防病毒系統,任選一種部署  
二、上雲服務器(如阿里雲):態勢感知或安騎士或其它防病毒服務

 

資源控制

•     a)應經過設定終端接入方式、網絡地址範圍等條件限制終端登陸;

•     整改方法:

•     驗證檢查:  
一、使用SSH登陸則查看/etc/ssh/sshd_config  
二、查看/etc/hosts.allow和/etc/hosts.deny文件內是否配置可訪問的IP或經過詢問、查看方式確認是否經過網絡設備或硬件防火牆實現此項要求;  
三、iptables -nvL 查看防火牆規則  
建議整改:  
(一)策略修改  
一、/etc/ssh/sshd_config文件中PermitRootLoginno,不容許root直接登陸  
二、/etc/hosts.allow和/etc/hosts.deny文件中配置可訪問的IP或者經過防火牆或跳板機或堡壘機設置訪問限制  
三、上雲的服務器:安全組或VPC或雲防火牆進行設置  
四、防火牆規則根據業務需求進行配置

•     b)應根據安全策略設置登陸終端的操做超時鎖定;

•     整改方法:

•     驗證檢查:  
一、查看etc/profile文件中是否設置TMOUT  
建議整改:  
(一)策略修改  
一、etc/profile文件中添加TMOUT,TMOUT=600(備註:根據業務進行設定)

•     d)應限制單個用戶對系統資源的最大或最小使用限度;

•     整改方法:

•     驗證檢查:  
一、查看 /etc/security/limits.conf 文件,訪談系統管理員針對系統資源採起的保障措施。  
fsize 用戶建立的文件大小限制; 
core 生成的core文件大小的限制;  
cpu 用戶進程可用cpu的限定值;  
data 進程數據段大小的限定值; 
stack 進程堆棧段大小的限定值; 
rss 進程常駐內存段的限定值; 
nofiles 進程中打開文件的最大數量。 
建議整改:  
一、根據實際需求對文件中的各個變量參數進行合理設置  
二、採用zabbix或者雲監控等手段進行監控

1.2.數據庫

1.2.1.    SQL數據庫

  • 身份鑑別

•     b)操做系統和數據庫系統管理用戶身份標識應具備不易被冒用的特色,口令應有複雜度要求並按期更換;

•     整改方法:

•     驗證檢查:  
一、打開Microsoft SQL Server Management Studio,對象資源管理器中--安全性--登陸名,  
右鍵各個用戶--屬性--常規--強制實施密碼策略、強制密碼過時策略;   
二、(數據庫部署的操做系統中)控制面板--管理工具--本地安全設置--賬戶策略--密碼策略:   
(1)、密碼必須符合複雜性要求;   
(2)、密碼長度最小值;   
(3)、密碼最長使用期限;   
(4)、密碼最短使用期限;   
(5)、強制密碼歷史;  
 三、在SQL 查詢分析器中執行 Use master; Select name,Password from syslogins where password is null 或 使用數據庫掃描軟件,查看掃描結果中是否存在空口令/弱口令的用戶。 
建議整改:  
(一)策略修改  
一、每一個用戶須要勾選「強制實施密碼策略」;  
二、密碼必須符合複雜性要求已啓用,密碼長度最小值0個字符,密碼最短使用期限0天,密碼最長使用期限42天,0個記住密碼  
三、未發現弱口令、空口令用戶  

•     c)應啓用登陸失敗處理功能,可採起結束會話、限制非法登陸次數和自動退出等措施;

•     整改方法:

•     驗證檢查:  
一、打開Microsoft SQL Server Management Studio,對象資源管理器中--安全性--登陸名,  
右鍵各個用戶--屬性--常規--強制實施密碼策略; 
 二、控制面板--管理工具--本地安全設置--賬戶策略--帳戶鎖定策略:   
(1)、復位賬號鎖定計數器;   
(2)、帳戶鎖定時間;  
(3)、帳戶鎖定閥值。  
建議整改:  
(一)策略修改  
一、每一個用戶須要勾選「強制實施密碼策略」;  
二、帳戶鎖定時間30分鐘,帳戶鎖定閾值5次無效登陸,重置帳戶鎖定計數器30分

•     f)應採用兩種或兩種以上組合的鑑別技術對管理用戶進行身份鑑別。

•     整改方法:

•     驗證檢查:  
一、採用令牌、USB-KEY或智能卡等身份認證技術手段對用戶進行身份鑑別  
建議整改:  
部署雙因素產品或者堡壘機

  • 訪問控制

•     d)應嚴格限制默認賬戶的訪問權限,重命名系統默認賬戶,修改這些賬戶的默認口令;

•     整改方法:

•     驗證檢查:  
打開Microsoft SQL Server Management Studio,對象資源管理器中--安全性--登陸名,查看是否存在sa賬號。  
建議整改:  
(一)策略修改  
一、對sa用戶重命名

  • 安全審計

•     a)審計範圍應覆蓋到服務器和重要客戶端上的每一個操做系統用戶和數據庫用戶;

•     b)審計內容應包括重要用戶行爲、系統資源的異常使用和重要系統命令的使用等系統內重要的安全相關事件;

•     c)審計記錄應包括事件的日期、時間、類型、主體標識、客體標識和結果等;

•     d)應可以根據記錄數據進行分析,並生成審計報表;

•     e)應保護審計進程,避免受到未預期的中斷;

•     f)應保護審計記錄,避免受到未預期的刪除、修改或覆蓋等。

•     總體分析

•     整改方法:

•     驗證檢查:  
打開Microsoft SQL Server Management Studio,對象資源管理器中,右鍵服務器--屬性--安全性   
一、登陸審覈;  
二、啓用C2審覈跟蹤。  
建議整改:  
(一)策略修改  
一、勾選僅限失敗的登陸, 勾選啓用C2審覈跟蹤  
(二)設備和服務部署  
部署數據庫審計系統  
1.2.2. mysql數據庫

  • 身份鑑別

•     b)操做系統和數據庫系統管理用戶身份標識應具備不易被冒用的特色,口令應有複雜度要求並按期更換;

•     整改方法:

•     驗證檢查:  
一、使用的口令(如默認賬號root)是否複雜度,而且是否認期進行更換  
建議整改:  
(一)策略修改  
一、用戶口令長度8位,至少由字母、數字及字符兩種以上的組合;  
二、按期更換口令。

•     c)應啓用登陸失敗處理功能,可採起結束會話、限制非法登陸次數和自動退出等措施;

•     整改方法:

•     驗證檢查:  
一、是否有登陸失敗處理措施  
建議整改:  
使用了第三方技術實現了登陸失敗處理功能。

•     e)應爲操做系統和數據庫系統的不一樣用戶分配不一樣的用戶名,確保用戶名具備惟一性;

•     整改方法:

•     驗證檢查:  
一、否存在多個用戶使用同一賬號的狀況。 
建議整改:  
一、不使用同一賬號進行管理

•     f)應採用兩種或兩種以上組合的鑑別技術對管理用戶進行身份鑑別。

•     整改方法:

•     驗證檢查:  
一、是否採用兩種或兩種以上組合的鑑別技術對管理用戶進行身份鑑別,且其中一種是不可僞造的  
建議整改:  
一、採用令牌、USB-KEY或智能卡進行身份鑑別(部署雙因子認證產品)

  • 安全審計

•     a)審計範圍應覆蓋到服務器和重要客戶端上的每一個操做系統用戶和數據庫用戶;

•     b)審計內容應包括重要用戶行爲、系統資源的異常使用和重要系統命令的使用等系統內重要的安全相關事件;

•     c)審計記錄應包括事件的日期、時間、類型、主體標識、客體標識和結果等;

•     d)應可以根據記錄數據進行分析,並生成審計報表;

•     e)應保護審計進程,避免受到未預期的中斷;

•     f)應保護審計記錄,避免受到未預期的刪除、修改或覆蓋等。

•     總體分析

•     整改方法:

•     驗證檢查:  
一、是否數據庫日誌和審計功能是否開啓 
二、是否對審計數據進行分析,並生成報表 
三、是否避免審計記錄被刪除、修改或覆蓋,是否至少知足6個月  
四、是否認期進行數據備份,是否有數據恢復措施 
建議整改:  
(一)產品或服務部署  
數據庫審計系統

•     日誌或自帶審計系統對性能影響巨大,產生大量文件消耗硬盤空間,事實上中大型系統都不能使用,或只能在排查問題時偶爾使用;日誌系統不直觀、易篡改、不完整、難管理;沒法自動智能設置規則; 另外,從安全管控的標準及法規角度來看,也須要第三方獨立的審計設備。

  • 入侵防範

•     a)應可以檢測到對重要服務器進行入侵的行爲,可以記錄入侵的源IP、攻擊的類型、攻擊的目的、攻擊的時間,並在發生嚴重入侵事件時提供報警;

•     b)應可以對重要程序的完整性進行檢測,並在檢測到完整性受到破壞後具備恢復的措施;

•     c)操做系統應遵循最小安裝的原則,僅安裝須要的組件和應用程序,並經過設置升級服務器等方式保持系統補丁及時獲得更新。

•     總體分析

•     整改方法:

•     建議整改:  
(一)產品或服務部署  
數據庫防火牆

2.  應用安全

2.1.       身份鑑別

  b)應對同一用戶採用兩種或兩種以上組合的鑑別技術實現用戶身份鑑別

整改方法:

驗證檢查:  
一、是否採用兩種或兩種以上組合的鑑別技術實現用戶身份鑑別  
建議整改:  
一、採用雙因素認證產品  
  

d)應提供登陸失敗處理功能,可採起結束會話、限制非法登陸次數和自動退出等措施;

e)應啓用身份鑑別、用戶身份標識惟一性檢查、用戶身份鑑別信息複雜度檢查以及登陸失敗處理功能,並根據安全策略配置相關參數。

總體分析

整改方法:

驗證檢查:  
一、連續屢次輸入口令錯誤,是否有帳號鎖定或者退出客戶端登陸等措施  
建議整改:  
一、屢次輸入錯誤口令,系統應該鎖定帳號和退出客戶端等措施

2.2.       安全審計

a)應提供覆蓋到每一個用戶的安全審計功能,對應用系統重要安全事件進行審計;

b)應保證沒法單獨中斷審計進程,沒法刪除、修改或覆蓋審計記錄;

c)審計記錄的內容至少應包括事件的日期、時間、發起者信息、類型、描述和結果等;

d)應提供對審計記錄數據進行統計、查詢、分析及生成審計報表的功能。

總體分析

整改方法:

驗證檢查:  
一、是否有安全審計功能模塊,包括到每一個用戶的安全審計功能(備註:用戶應該包括內部運維用戶和使用者用戶)  
二、是否審計進程能中斷,審計記錄是否能被刪除、修改和覆蓋  
三、審計的記錄至少包括:時間、日期、發起者信息、類型、描述和結果  
四、是否對審計記錄進行查詢、分析、統計和生成審計報表  
建議整改:  
一、審計包括客戶及內部人員,包括應用系統的重要安全事件:帳戶創建、用戶權限分配、重要業務數據操做、用戶身份鑑別失敗等(備註:審計的內容會根據每個行業的業務方向有所不一樣)  
二、審計記錄至少保存6個月  
三、審計記錄須要按期進行查詢、分析,生成對應的審計報表

軟件容錯

a)應提供數據有效性檢驗功能,保證經過人機接口輸入或經過通訊接口輸入的數據格式或長度符合系統設定要求;

b)應提供自動保護功能,當故障發生時自動保護當前全部狀態,保證系統可以進行恢復。

總體分析

整改方法:

驗證檢查:  
一、檢查系統是否在數據輸入界面對無效或非法的數據進行校驗  
二、是否對數據的格式或長度進行校驗 
三、檢查系統返回的錯誤信息中是否含有sql語句、sql錯誤信息以及web服務器的絕對路徑等 
四、若系統有上傳功能,嘗試上傳與服務器端語言(jsp、asp、php)同樣擴展名的文件或exe等  
可執行文件後,確認在服務器端是否可直接運行 
建議整改:  
一、註冊用戶是否能夠'—'、‘1=1’等恆等式用戶名  
二、上傳給服務器的參數(如查詢關鍵字、url中的參數等)中包含特殊字符是否能正常處理  
三、不存在SQL注入、XSS跨站腳本等漏洞  
四、部署WAF或網頁防篡改等第三方產品

 

資源控制

a)當應用系統的通訊雙方中的一方在一段時間內未做任何響應,另外一方應可以自動結束會話;

b)應可以對系統的最大併發會話鏈接數進行限制;

c)應可以對單個賬戶的多重併發會話進行限制;

d)應可以對一個時間段內可能的併發會話鏈接數進行限制;

e)應可以對一個訪問賬戶或一個請求進程佔用的資源分配最大限額和最小限額;

f)應可以對系統服務水平下降到預先規定的最小值進行檢測和報警;

g)應提供服務優先級設定功能,並在安裝後根據安全策略設定訪問賬戶或請求進程的優先級,根據優先級分配系統資源。

總體分析

整改方法:

驗證檢查:  
一、系統是否具備超時結束會話功能 
二、系統是否有最大併發會話鏈接數限制 
三、系統是否限制單個用戶多重併發會話數 
四、系統是否設置資源限額  
建議整改:  
一、可以在合理的時間內結束超時空閒會話 
二、禁止同一個用戶同時登陸系統操做(備註:根據自身業務狀況而定)  
三、可以對一個訪問帳戶或一個請求進程佔用的資源分配最大和最小限額

3.  數據庫安全及備份恢復

3.1.       備份和恢復

b)應提供異地數據備份功能,利用通訊網絡將關鍵數據定時批量傳送至備用場地;

整改方法:

建議整改:  
網絡和安全設備的策略配置文件進行異地備份,數據庫數據進行異地備份;

4.  系統運維管理

4.1.       監控管理和安全管理中心

b)應組織相關人員按期對監測和報警記錄進行分析、評審,發現可疑行爲,造成分析報告,並採起必要的應對措施;

整改方法:

建議整改:  
一、對監測和告警記錄有按期的分析報告和對應措施

c)應創建安全管理中心,對設備狀態、惡意代碼、補丁升級、安全審計等安全相關事項進行集中管理。

整改方法:

建議整改:  
一、創建安全管理中心,對設備狀態、惡意代碼、補丁升級、安全審計等安全相關事項進行集中管理

 

網絡安全管理

d)應按期對網絡系統進行漏洞掃描,對發現的網絡系統安全漏洞進行及時的修補;

整改方法:

建議整改:  
一、按期的網絡設備掃描,並有掃描報告和整改結果

h)應按期檢查違反規定撥號上網或其餘違反網絡安全策略的行爲。

整改方法:

建議整改:  
一、用戶單位按期檢查違反規定撥號上網或其餘違反網絡安全策略的行爲

4.2.       系統安全管理

b)應按期進行漏洞掃描,對發現的系統安全漏洞及時進行修補;

整改方法:

建議整改:  
一、按期掃描系統漏洞,及時安裝安全補丁,及時進行漏洞修補

c)應安裝系統的最新補丁程序,在安裝系統補丁前,首先在測試環境中測試經過,並對重要文件進行備份後,方可實施系統補丁程序的安裝;

整改方法:

建議整改:  
一、及時作補丁修補,且安裝前補丁通過測試和系統備份

g)應按期對運行日誌和審計數據進行分析,以便及時發現異常行爲。

整改方法:

建議整改:  
一、按期對運行日誌和審計數據進行分析

4.3.       惡意代碼防範管理

b)應指定專人對網絡和主機進行惡意代碼檢測並保存檢測記錄;

整改方法:

建議整改:  
一、有專人對網絡和主機進行惡意代碼檢測,並保存檢測記錄

d)應按期檢查信息系統內各類產品的惡意代碼庫的升級狀況並進行記錄,對主機防病毒產品、防病毒網關和郵件防病毒網關上截獲的危險病毒或惡意代碼進行及時分析處理,並造成書面的報表和總結匯報。

整改方法:

建議整改:  
一、對系統內的惡意代碼防範產品的升級狀況予以按期檢查和記錄,並對安全日誌進行按期分析並造成報告

4.4.       備份與恢復管理

e)應按期執行恢復程序,檢查和測試備份介質的有效性,確保能夠在恢復程序規定的時間內完成備份的恢復。

整改方法:

建議整改:  
一、按期測試備份介質的有效性,按期執行恢復程序,肯定在規定的時間內完成備份恢復

4.5.       應急預案管理

c)應對系統相關的人員進行應急預案培訓,應急預案的培訓應至少每一年舉辦一次;

整改方法:

建議整改:  
一、對系統相關人員進行應急預案的培訓,培訓至少每一年舉辦一次,並保留培訓記錄

d)應按期對應急預案進行演練,根據不一樣的應急恢復內容,肯定演練的週期;

整改方法:

建議整改:  
一、按期對應急預案進行演練,並保留演練記錄

5.  系統建設管理

5.1.       產品採購和使用

d)應預先對產品進行選型測試,肯定產品的候選範圍,並按期審定和更新候選產品名單。

整改方法:

建設整改:  
有產品選型測試記錄或選型報告、候選產品名單(或候選供應商名錄)並按期更新

5.2.       外包軟件開發

d)應要求開發單位提供軟件源代碼,並審查軟件中可能存在的後門。

整改方法:

建議整改:  
一、在軟件開發協議中,規定開發單位提供軟件源代碼,並進行後門審查

5.3.       測試驗收

a)應委託公正的第三方測試單位對系統進行安全性測試,並出具安全性測試報告;

整改方法:

建議整改:  
一、委託公認的第三方測評單位對系統進行安全測評,並有測試報告

6.  人員安全管理

6.1.       人員考覈

a)應按期對各個崗位的人員進行安全技能及安全認知的考覈;

b)應對關鍵崗位的人員進行全面、嚴格的安全審查和技能考覈;

c)應對考覈結果進行記錄並保存。

總體分析

整改方法:

建議整改:  
一、有按期安全技能和知識的考覈,有考覈記錄 
二、有按期對關鍵崗位的安全考試,有考覈記錄

6.2.       安全意識的教育和培訓

d)應對安全教育和培訓的狀況和結果進行記錄並歸檔保存。

整改方法:

建議整改:  
一、對培訓的記錄和結果歸檔保存

7.  安全管理機構

7.1.       人員配備

b)應配備專職安全管理員,不可兼任;

整改方法:

建議整改:  
一、配備安全管理員,安全管理員可兼任非系統維護工做

c)關鍵事務崗位應配備多人共同管理。

整改方法:

建議整改:  
一、關鍵崗位設置多人或AB角

7.2.       受權和審批

d)應記錄審批過程並保存審批文檔。

整改方法:

建議整改:  
一、保存審批記錄

7.3.       溝通和合做

a)應增強各種管理人員之間、組織內部機構之間以及信息安全職能部門內部的合做與溝通,按期或不按期召開協調會議,共同協做處理信息安全問題;

整改方法:

建議整改:  
一、按期召開信息安全會議,保存有會議紀要

e)應聘請信息安全專家做爲常年的安全顧問,指導信息安全建設,參與安全規劃和安全評審等。

整改方法:

建議整改:  
一、聘請信息安全專家

7.4.       審覈和檢查

a)安全管理員應負責按期進行安全檢查,檢查內容包括系統平常運行、系統漏洞和數據備份等狀況;

整改方法:

建議整改:  
一、按期進行安全檢查,有檢查內容及結果記錄文檔

b)應由內部人員或上級單位按期進行全面安全檢查,檢查內容包括現有安全技術措施的有效性、安全配置與安全策略的一致性、安全管理制度的執行狀況等;

整改方法:

建議整改:  
一、內部或上級單位按期全面檢查,或行業主管部門委託第三方進行檢查

c)應制定安全檢查表格實施安全檢查,彙總安全檢查數據,造成安全檢查報告,並對安全檢查結果進行通報;

整改方法:

建議整改:  
一、保存有安全檢查記錄和檢查報告

8.  安全管理制度

8.1.       制定和發佈

c)應組織相關人員對制定的安全管理制度進行論證和審定;

整改方法:

建議整改:  
只要有證據(郵件、會議紀要、OA系統中流轉記錄、文件評審記錄等)代表在安全管理制度發佈前已進行相關的論證和審定

8.2.       評審和修訂

a)信息安全領導小組應負責按期組織相關部門和相關人員對安全管理制度體系的合理性和適用性進行審定;

整改方法:

建議整改:  
一、沒有至少評審一次  
二、至少有評審記錄

b)應按期或不按期對安全管理制度進行檢查和審定,對存在不足或須要改進的安全管理制度進行修訂。

整改方法:

建議整改:  
一、每一年至少評審一次  
二、文件修改記錄  三、文件評審記錄

相關文章
相關標籤/搜索