centos/Fedora/RHEL
• 整改方法：
• 验证检查：
1、查看/etc/login.defs，访谈询问当前所设置的密码长度及更换周期；
2、查看/etc/pam.d/system-auth，确认密码复杂度要求。
密码最长有效期PASS_MAX_DAYS；
密码最短存留期PASS_MIN_DAYS；
密码长度最小值PASS_MIN_LENS；
密码有效期警告PASS_WARN_AEG；
密码须包含大写字母个数ucredit；
密码须包含小写字母个数lcredit；
密码须包含的数字字符个数dcredit；
密码须包含的特殊符号个数ocredit。
建议整改：
（一）策略修改
1、/etc/login.defs文件中进行如下变量配置：
PASS_MAX_DAYS：90；
PASS_MIN_DAYS：2；
PASS_MIN_LENS：8；
PASS_WARN_AEG：7；
2、/etc/pam.d/system-auth文件中添加下面信息：
password requisite pam_cracklib.so minlen=8 ucredit=-1 lcredit=-1 dcredit=-1ocredit=-1；
3、当前所设置的密码长度应不少于8位，具有一定的复杂度并能定期更换。
• Ubuntu/Debian
• 整改方法：
• 验证检查：
1、查看/etc/login.defs，访谈询问当前所设置的密码长度及更换周期；
2、查看/etc/pam.d/common-password，确认密码复杂度要求。
密码最长有效期PASS_MAX_DAYS；
密码最短存留期PASS_MIN_DAYS；
密码长度最小值PASS_MIN_LENS；
密码有效期警告PASS_WARN_AEG；
密码须包含大写字母个数ucredit；
密码须包含小写字母个数lcredit；
密码须包含的数字字符个数dcredit；
密码须包含的特殊符号个数ocredit。
建议整改：
（一）策略修改
1、/etc/login.defs文件中进行如下变量配置：
PASS_MAX_DAYS：90；
PASS_MIN_DAYS：2；
PASS_MIN_LENS：8；
PASS_WARN_AEG：7；
2、/etc/pam.d/system-auth文件中添加下面信息：
password requisite pam_cracklib.so minlen=8 ucredit=-1 lcredit=-1 dcredit=-1ocredit=-1；
3、当前所设置的密码长度应不少于8位，具有一定的复杂度并能定期更换。
• c)应启用登录失败处理功能，可采取结束会话、限制非法登录次数和自动退出等措施；
• 整改方法：
• 验证检查：
1、find /lib* -iname “pam_tally2.so”或find /lib* -iname “pam_tally.so”是否有改动态库
2、是否有以下参数：auth required pam_tally2.so onerr=fail deny=X unlock_time=Xeven_deny_root root_unlock_time=X（限制从终端登录）
3、/etc/pam.d/sshd文件中是否有以上相同参数（限制ssh登录）
建议整改：
1、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 次登录失败即锁定。
2、/etc/pam.d/sshd文件中添加相同参数
（备注：以上参数根据实际情况进行设置，至少配置/etc/pam.d/sshd文件限制ssh登录）
• f)应采用两种或两种以上组合的鉴别技术对管理用户进行身份鉴别。
• 整改方法：
• 验证检查：
操作系统登录是否采用口令+令牌、USB KEY等方式进行身份鉴别。
建议整改：
（一）设备或服务部署
1、物理机房：采用双因子认证设备
2、上云服务器（如阿里云）：云堡垒机
访问控制
• a)应启用访问控制功能，依据安全策略控制用户对资源的访问；
• 整改方法：
• 验证检查：
是否能提供用户权限对照表，设置的用户权限是否与权限表一致。
建议整改：
完善用户权限表（纸质版或电子版）
• d)应严格限制默认帐户的访问权限，重命名系统默认帐户，修改这些帐户的默认口令；
• 整改方法：
• 验证检查：
1、重命名系统默认帐户（root）；
2、修改默认帐户的口令。
建议整改：
1、根据业务需求情况对root进行重命名，其口令必须进行修改
• f)应对重要信息资源设置敏感标记；
• 整改方法：
• 验证检查：
1、询问主机管理员是否定义了主机中的重要信息资源；
2、询问主机管理员，是否为主机内的重要信息设置敏感标记。
建议整改：
暂无
• g)应依据安全策略严格控制用户对有敏感标记重要信息资源的操作。
• 整改方法：
• 验证检查：
1、询问主机管理员是否定义了敏感标记资源的访问策略；
2、查看有敏感标记的重要信息资源是否依据访问策略设置了严格的访问权限。
建议整改：
暂无
备注：linux系统分为Ubuntu、OpenSUSE、Fedora、Debian、RHEL、CentOS等，每个系统又分为不同的版本，因此在修改策略时需要在相同环境的测试机上进行验证后，在正式环境中进行修改
安全审计
• a)审计范围应覆盖到服务器上的每个操作系统用户和数据库用户；
• b)审计内容应包括重要用户行为、系统资源的异常使用和重要系统命令的使用等系统内重要的安全相关事件；
• c)审计记录应包括事件的日期、时间、类型、主体标识、客体标识和结果等；
• d)应能够根据记录数据进行分析，并生成审计报表；
• e)应保护审计进程，避免受到未预期的中断；
• f)应保护审计记录，避免受到未预期的删除、修改或覆盖等。
• 整体分析
• 整改方法：
• 验证检查：
1、输入service syslog/rsyslog status 、service auditd status查看进程是否存在。
2、（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；）
3、是否对审计日志定期查看、分析，生成审计分析报表
4、是否安全额外的审计进程保护
5、查看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；
访谈并询问是否对审计日志进行保护
建议整改：
（一）策略修改
1、保障rsyslog和auditd进程开启
2、/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
（备注：以上配置需要先在测试环境中验证是否正确后，在正式环境中进行修改）
3、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；（备注：保持系统默认就行，唯一需要满足的就是普通用户对这些文件只能有读的权限）
4、查看 /var/log/messages、/var/log/secure、/var/log/audit/audit.log、/var/log/auth.log日志文件的内容是否被覆盖和删除，保存是否满足6个月
（二）设备或服务部署
1、物理机房：日志服务器或日志审计系统或堡垒机
2、上云服务器（如阿里云）：OSS或日志服务或jumpserver
入侵防范
• a)应能够检测到对重要服务器进行入侵的行为，能够记录入侵的源IP、攻击的类型、攻击的目的、攻击的时间，并在发生严重入侵事件时提供报警；
• 整改方法：
• 验证检查：
1、安装主机入侵检测系统并配置策略；
2、定期对主机入侵检测系统的特征库进行维护升级；
3、发生严重入侵事件时提供报警。
4、是否经常命令查看more /var/log/secure | grep refused (centos)
5、more /var/log/auth.log | grep refused (ubuntu)
6、是否启用主机iptables防火墙规则、TCP SYN保护机制
建议整改：
（一）设备或服务部署
1、物理机房：部署入侵检测和防御系统（IDS、IPS或防火墙带有入侵检测和防御）
2、上云服务器（如阿里云）：安骑士或态势感知或其它防入侵服务
• c)操作系统应遵循最小安装的原则，仅安装需要的组件和应用程序，并通过设置升级服务器等方式保持系统补丁及时得到更新。
• 整改方法：
• 验证检查：
1、对系统补丁进行评估、测试后进行安装
2、系统遵循最小安装原则
建议整改：
（一）策略修改
1、如需最新补丁，需要评估、测试，或者根据业务使用稳定版本补丁
2、关闭危险网络服务：echo、login等，关闭非必要的网络服务：talk、ntalk、sendmail等
恶意代码防范
• a)应安装防恶意代码软件，并及时更新防恶意代码软件版本和恶意代码库；
• b)主机防恶意代码产品应具有与网络防恶意代码产品不同的恶意代码库；
• c)应支持防恶意代码软件的统一管理。
• 整体考虑
• 整改方法：
• 验证检查：
1、查看是否安装了防恶意代码软件；
2、查看恶意代码库是否为最新；
3、主机防病毒软件是否与网络版防病毒软件相同
4、安装的防病毒软件是否支持统一管理
建议整改：
（一）设备和服务部署
1、物理机房：防病毒网关、包含防病毒模块的多功能安全网关和网络版防病毒系统，任选一种部署
2、上云服务器（如阿里云）：态势感知或安骑士或其它防病毒服务
资源控制
• a)应通过设定终端接入方式、网络地址范围等条件限制终端登录；
• 整改方法：
• 验证检查：
1、使用SSH登录则查看/etc/ssh/sshd_config
2、查看/etc/hosts.allow和/etc/hosts.deny文件内是否配置可访问的IP或通过询问、查看方式确认是否通过网络设备或硬件防火墙实现此项要求；
3、iptables -nvL 查看防火墙规则
建议整改：
（一）策略修改
1、/etc/ssh/sshd_config文件中PermitRootLoginno，不允许root直接登录
2、/etc/hosts.allow和/etc/hosts.deny文件中配置可访问的IP或者通过防火墙或跳板机或堡垒机设置访问限制
3、上云的服务器：安全组或VPC或云防火墙进行设置
4、防火墙规则根据业务需求进行配置
• b)应根据安全策略设置登录终端的操作超时锁定；
• 整改方法：
• 验证检查：
1、查看etc/profile文件中是否设置TMOUT
建议整改：
（一）策略修改
1、etc/profile文件中添加TMOUT，TMOUT=600（备注：根据业务进行设定）
• d)应限制单个用户对系统资源的最大或最小使用限度；
• 整改方法：
• 验证检查：
1、查看 /etc/security/limits.conf 文件，访谈系统管理员针对系统资源采取的保障措施。
fsize 用户创建的文件大小限制；
core 生成的core文件大小的限制；
cpu 用户进程可用cpu的限定值；
data 进程数据段大小的限定值；
stack 进程堆栈段大小的限定值；
rss 进程常驻内存段的限定值；
nofiles 进程中打开文件的最大数量。
建议整改：
1、根据实际需求对文件中的各个变量参数进行合理设置
2、采用zabbix或者云监控等手段进行监控
1.2.数据库
1.2.1. SQL数据库
-
身份鉴别
• b)操作系统和数据库系统管理用户身份标识应具有不易被冒用的特点，口令应有复杂度要求并定期更换；
• 整改方法：
• 验证检查：
1、打开Microsoft SQL Server Management Studio，对象资源管理器中–安全性–登录名，
右键各个用户–属性–常规–强制实施密码策略、强制密码过期策略；
2、（数据库部署的操作系统中）控制面板–管理工具–本地安全设置–帐户策略–密码策略：
（1）、密码必须符合复杂性要求；
（2）、密码长度最小值；
（3）、密码最长使用期限；
（4）、密码最短使用期限；
（5）、强制密码历史；
3、在SQL 查询分析器中执行 Use master； Select name，Password from syslogins where password is null 或 使用数据库扫描软件，查看扫描结果中是否存在空口令/弱口令的用户。
建议整改：
（一）策略修改
1、每个用户需要勾选“强制实施密码策略”；
2、密码必须符合复杂性要求已启用，密码长度最小值0个字符，密码最短使用期限0天，密码最长使用期限42天，0个记住密码
3、未发现弱口令、空口令用户
• c)应启用登录失败处理功能，可采取结束会话、限制非法登录次数和自动退出等措施；
• 整改方法：
• 验证检查：
1、打开Microsoft SQL Server Management Studio，对象资源管理器中–安全性–登录名，
右键各个用户–属性–常规–强制实施密码策略；
2、控制面板–管理工具–本地安全设置–帐户策略–账户锁定策略：
（1）、复位帐号锁定计数器；
（2）、账户锁定时间；
（3）、账户锁定阀值。
建议整改：
（一）策略修改
1、每个用户需要勾选“强制实施密码策略”；
2、账户锁定时间30分钟，账户锁定阈值5次无效登录，重置账户锁定计数器30分
• f)应采用两种或两种以上组合的鉴别技术对管理用户进行身份鉴别。
• 整改方法：
• 验证检查：
1、采用令牌、USB-KEY或智能卡等身份认证技术手段对用户进行身份鉴别
建议整改：
部署双因素产品或者堡垒机
-
访问控制
• d)应严格限制默认帐户的访问权限，重命名系统默认帐户，修改这些帐户的默认口令；
• 整改方法：
• 验证检查：
打开Microsoft SQL Server Management Studio，对象资源管理器中–安全性–登录名，查看是否存在sa帐号。
建议整改：
（一）策略修改
1、对sa用户重命名
-
安全审计
• a)审计范围应覆盖到服务器和重要客户端上的每个操作系统用户和数据库用户；
• b)审计内容应包括重要用户行为、系统资源的异常使用和重要系统命令的使用等系统内重要的安全相关事件；
• c)审计记录应包括事件的日期、时间、类型、主体标识、客体标识和结果等；
• d)应能够根据记录数据进行分析，并生成审计报表；
• e)应保护审计进程，避免受到未预期的中断；
• f)应保护审计记录，避免受到未预期的删除、修改或覆盖等。
• 整体分析
• 整改方法：
• 验证检查：
打开Microsoft SQL Server Management Studio，对象资源管理器中，右键服务器–属性–安全性
1、登录审核；
2、启用C2审核跟踪。
建议整改：
（一）策略修改
1、勾选仅限失败的登录， 勾选启用C2审核跟踪
（二）设备和服务部署
部署数据库审计系统
1.2.2. mysql数据库
-
身份鉴别
• b)操作系统和数据库系统管理用户身份标识应具有不易被冒用的特点，口令应有复杂度要求并定期更换；
• 整改方法：
• 验证检查：
1、使用的口令（如默认帐号root）是否复杂度，并且是否定期进行更换
建议整改：
（一）策略修改
1、用户口令长度8位，至少由字母、数字及字符两种以上的组合；
2、定期更换口令。
• c)应启用登录失败处理功能，可采取结束会话、限制非法登录次数和自动退出等措施；
• 整改方法：
• 验证检查：
1、是否有登录失败处理措施
建议整改：
使用了第三方技术实现了登录失败处理功能。
• e)应为操作系统和数据库系统的不同用户分配不同的用户名，确保用户名具有唯一性；
• 整改方法：
• 验证检查：
1、否存在多个用户使用同一帐号的情况。
建议整改：
1、不使用同一帐号进行管理
• f)应采用两种或两种以上组合的鉴别技术对管理用户进行身份鉴别。
• 整改方法：
• 验证检查：
1、是否采用两种或两种以上组合的鉴别技术对管理用户进行身份鉴别，且其中一种是不可伪造的
建议整改：
1、采用令牌、USB-KEY或智能卡进行身份鉴别（部署双因子认证产品）
-
安全审计
• a)审计范围应覆盖到服务器和重要客户端上的每个操作系统用户和数据库用户；
• b)审计内容应包括重要用户行为、系统资源的异常使用和重要系统命令的使用等系统内重要的安全相关事件；
• c)审计记录应包括事件的日期、时间、类型、主体标识、客体标识和结果等；
• d)应能够根据记录数据进行分析，并生成审计报表；
• e)应保护审计进程，避免受到未预期的中断；
• f)应保护审计记录，避免受到未预期的删除、修改或覆盖等。
• 整体分析
• 整改方法：
• 验证检查：
1、是否数据库日志和审计功能是否开启
2、是否对审计数据进行分析，并生成报表
3、是否避免审计记录被删除、修改或覆盖，是否至少满足6个月
4、是否定期进行数据备份，是否有数据恢复措施
建议整改：
（一）产品或服务部署
数据库审计系统
• 日志或自带审计系统对性能影响巨大，产生大量文件消耗硬盘空间，事实上中大型系统都不能使用，或只能在排查问题时偶尔使用;日志系统不直观、易篡改、不完整、难管理;无法自动智能设置规则; 另外，从安全管控的标准及法规角度来看，也需要第三方独立的审计设备。
-
入侵防范
• a)应能够检测到对重要服务器进行入侵的行为，能够记录入侵的源IP、攻击的类型、攻击的目的、攻击的时间，并在发生严重入侵事件时提供报警；
• b)应能够对重要程序的完整性进行检测，并在检测到完整性受到破坏后具有恢复的措施；
• c)操作系统应遵循最小安装的原则，仅安装需要的组件和应用程序，并通过设置升级服务器等方式保持系统补丁及时得到更新。
• 整体分析
• 整改方法：
• 建议整改：
（一）产品或服务部署
数据库防火墙
2. 应用安全
2.1. 身份鉴别
b)应对同一用户采用两种或两种以上组合的鉴别技术实现用户身份鉴别
整改方法：
验证检查：
1、是否采用两种或两种以上组合的鉴别技术实现用户身份鉴别
建议整改：
1、采用双因素认证产品
d)应提供登录失败处理功能，可采取结束会话、限制非法登录次数和自动退出等措施；
e)应启用身份鉴别、用户身份标识唯一性检查、用户身份鉴别信息复杂度检查以及登录失败处理功能，并根据安全策略配置相关参数。
整体分析
整改方法：
验证检查：
1、连续多次输入口令错误，是否有账号锁定或者退出客户端登录等措施
建议整改：
1、多次输入错误口令，系统应该锁定账号和退出客户端等措施
2.2. 安全审计
a)应提供覆盖到每个用户的安全审计功能，对应用系统重要安全事件进行审计；
b)应保证无法单独中断审计进程，无法删除、修改或覆盖审计记录；
c)审计记录的内容至少应包括事件的日期、时间、发起者信息、类型、描述和结果等；
d)应提供对审计记录数据进行统计、查询、分析及生成审计报表的功能。
整体分析
整改方法：
验证检查：
1、是否有安全审计功能模块，包括到每个用户的安全审计功能（备注：用户应该包括内部运维用户和使用者用户）
2、是否审计进程能中断，审计记录是否能被删除、修改和覆盖
3、审计的记录至少包括：时间、日期、发起者信息、类型、描述和结果
4、是否对审计记录进行查询、分析、统计和生成审计报表
建议整改：
1、审计包括客户及内部人员，包括应用系统的重要安全事件：账户建立、用户权限分配、重要业务数据操作、用户身份鉴别失败等（备注：审计的内容会根据每一个行业的业务方向有所不同）
2、审计记录至少保存6个月
3、审计记录需要定期进行查询、分析，生成对应的审计报表
软件容错
a)应提供数据有效性检验功能，保证通过人机接口输入或通过通信接口输入的数据格式或长度符合系统设定要求；
b)应提供自动保护功能，当故障发生时自动保护当前所有状态，保证系统能够进行恢复。
整体分析
整改方法：
验证检查：
1、检查系统是否在数据输入界面对无效或非法的数据进行校验
2、是否对数据的格式或长度进行校验
3、检查系统返回的错误信息中是否含有sql语句、sql错误信息以及web服务器的绝对路径等
4、若系统有上传功能，尝试上传与服务器端语言（jsp、asp、php）一样扩展名的文件或exe等
可执行文件后，确认在服务器端是否可直接运行
建议整改：
1、注册用户是否可以’—’、‘1=1’等恒等式用户名
2、上传给服务器的参数（如查询关键字、url中的参数等）中包含特殊字符是否能正常处理
3、不存在SQL注入、XSS跨站脚本等漏洞
4、部署WAF或网页防篡改等第三方产品
资源控制
a)当应用系统的通信双方中的一方在一段时间内未作任何响应，另一方应能够自动结束会话；
b)应能够对系统的最大并发会话连接数进行限制；
c)应能够对单个帐户的多重并发会话进行限制；
d)应能够对一个时间段内可能的并发会话连接数进行限制；
e)应能够对一个访问帐户或一个请求进程占用的资源分配最大限额和最小限额；
f)应能够对系统服务水平降低到预先规定的最小值进行检测和报警；
g)应提供服务优先级设定功能，并在安装后根据安全策略设定访问帐户或请求进程的优先级，根据优先级分配系统资源。
整体分析
整改方法：
验证检查：
1、系统是否具有超时结束会话功能
2、系统是否有最大并发会话连接数限制
3、系统是否限制单个用户多重并发会话数
4、系统是否设置资源限额
建议整改：
1、能够在合理的时间内结束超时空闲会话
2、禁止同一个用户同时登录系统操作（备注：根据自身业务情况而定）
3、能够对一个访问账户或一个请求进程占用的资源分配最大和最小限额
3. 数据库安全及备份恢复
3.1. 备份和恢复
b)应提供异地数据备份功能，利用通信网络将关键数据定时批量传送至备用场地；
整改方法：
建议整改：
网络和安全设备的策略配置文件进行异地备份，数据库数据进行异地备份；
4. 系统运维管理
4.1. 监控管理和安全管理中心
b)应组织相关人员定期对监测和报警记录进行分析、评审，发现可疑行为，形成分析报告，并采取必要的应对措施；
整改方法：
建议整改：
1、对监测和告警记录有定期的分析报告和对应措施
c)应建立安全管理中心，对设备状态、恶意代码、补丁升级、安全审计等安全相关事项进行集中管理。
整改方法：
建议整改：
1、建立安全管理中心，对设备状态、恶意代码、补丁升级、安全审计等安全相关事项进行集中管理
网络安全管理
d)应定期对网络系统进行漏洞扫描，对发现的网络系统安全漏洞进行及时的修补；
整改方法：
建议整改：
1、定期的网络设备扫描，并有扫描报告和整改结果
h)应定期检查违反规定拨号上网或其他违反网络安全策略的行为。
整改方法：
建议整改：
1、用户单位定期检查违反规定拨号上网或其他违反网络安全策略的行为
4.2. 系统安全管理
b)应定期进行漏洞扫描，对发现的系统安全漏洞及时进行修补；
整改方法：
建议整改：
1、定期扫描系统漏洞，及时安装安全补丁，及时进行漏洞修补
c)应安装系统的最新补丁程序，在安装系统补丁前，首先在测试环境中测试通过，并对重要文件进行备份后，方可实施系统补丁程序的安装；
整改方法：
建议整改：
1、及时做补丁修补，且安装前补丁经过测试和系统备份
g)应定期对运行日志和审计数据进行分析，以便及时发现异常行为。
整改方法：
建议整改：
1、定期对运行日志和审计数据进行分析
4.3. 恶意代码防范管理
b)应指定专人对网络和主机进行恶意代码检测并保存检测记录；
整改方法：
建议整改：
1、有专人对网络和主机进行恶意代码检测，并保存检测记录
d)应定期检查信息系统内各种产品的恶意代码库的升级情况并进行记录，对主机防病毒产品、防病毒网关和邮件防病毒网关上截获的危险病毒或恶意代码进行及时分析处理，并形成书面的报表和总结汇报。
整改方法：
建议整改：
1、对系统内的恶意代码防范产品的升级情况予以定期检查和记录，并对安全日志进行定期分析并形成报告
4.4. 备份与恢复管理
e)应定期执行恢复程序，检查和测试备份介质的有效性，确保可以在恢复程序规定的时间内完成备份的恢复。
整改方法：
建议整改：
1、定期测试备份介质的有效性，定期执行恢复程序，确定在规定的时间内完成备份恢复
4.5. 应急预案管理
c)应对系统相关的人员进行应急预案培训，应急预案的培训应至少每年举办一次；
整改方法：
建议整改：
1、对系统相关人员进行应急预案的培训，培训至少每年举办一次，并保留培训记录
d)应定期对应急预案进行演练，根据不同的应急恢复内容，确定演练的周期；
整改方法：
建议整改：
1、定期对应急预案进行演练，并保留演练记录
5. 系统建设管理
5.1. 产品采购和使用
d)应预先对产品进行选型测试，确定产品的候选范围，并定期审定和更新候选产品名单。
整改方法：
建设整改：
有产品选型测试记录或选型报告、候选产品名单（或候选供应商名录）并定期更新
5.2. 外包软件开发
d)应要求开发单位提供软件源代码，并审查软件中可能存在的后门。
整改方法：
建议整改：
1、在软件开发协议中，规定开发单位提供软件源代码，并进行后门审查
5.3. 测试验收
a)应委托公正的第三方测试单位对系统进行安全性测试，并出具安全性测试报告；
整改方法：
建议整改：
1、委托公认的第三方测评单位对系统进行安全测评，并有测试报告
6. 人员安全管理
6.1. 人员考核
a)应定期对各个岗位的人员进行安全技能及安全认知的考核；
b)应对关键岗位的人员进行全面、严格的安全审查和技能考核；
c)应对考核结果进行记录并保存。
整体分析
整改方法：
建议整改：
1、有定期安全技能和知识的考核，有考核记录
2、有定期对关键岗位的安全考试，有考核记录
6.2. 安全意识的教育和培训
d)应对安全教育和培训的情况和结果进行记录并归档保存。
整改方法：
建议整改：
1、对培训的记录和结果归档保存
7. 安全管理机构
7.1. 人员配备
b)应配备专职安全管理员，不可兼任；
整改方法：
建议整改：
1、配备安全管理员，安全管理员可兼任非系统维护工作
c)关键事务岗位应配备多人共同管理。
整改方法：
建议整改：
1、关键岗位设置多人或AB角
7.2. 授权和审批
d)应记录审批过程并保存审批文档。
整改方法：
建议整改：
1、保存审批记录
7.3. 沟通和合作
a)应加强各类管理人员之间、组织内部机构之间以及信息安全职能部门内部的合作与沟通，定期或不定期召开协调会议，共同协作处理信息安全问题；
整改方法：
建议整改：
1、定期召开信息安全会议，保存有会议纪要
e)应聘请信息安全专家作为常年的安全顾问，指导信息安全建设，参与安全规划和安全评审等。
整改方法：
建议整改：
1、聘请信息安全专家
7.4. 审核和检查
a)安全管理员应负责定期进行安全检查，检查内容包括系统日常运行、系统漏洞和数据备份等情况；
整改方法：
建议整改：
1、定期进行安全检查，有检查内容及结果记录文档
b)应由内部人员或上级单位定期进行全面安全检查，检查内容包括现有安全技术措施的有效性、安全配置与安全策略的一致性、安全管理制度的执行情况等；
整改方法：
建议整改：
1、内部或上级单位定期全面检查，或行业主管部门委托第三方进行检查
c)应制定安全检查表格实施安全检查，汇总安全检查数据，形成安全检查报告，并对安全检查结果进行通报；
整改方法：
建议整改：
1、保存有安全检查记录和检查报告
8. 安全管理制度
8.1. 制定和发布
c)应组织相关人员对制定的安全管理制度进行论证和审定；
整改方法：
建议整改：
只要有证据（邮件、会议纪要、OA系统中流转记录、文件评审记录等）表明在安全管理制度发布前已进行相关的论证和审定
8.2. 评审和修订
a)信息安全领导小组应负责定期组织相关部门和相关人员对安全管理制度体系的合理性和适用性进行审定；
整改方法：
建议整改：
1、没有至少评审一次
2、至少有评审记录
b)应定期或不定期对安全管理制度进行检查和审定，对存在不足或需要改进的安全管理制度进行修订。
整改方法：
建议整改：
1、每年至少评审一次
2、文件修改记录
3、文件评审记录
