等保测评高风险判定——安全计算环境（应用系统）篇

提示：文章如有错误，欢迎指出。

---

前言

等保测评的意义：一、降低信息安全风险，提高信息系统的安全防护能力；二、满足国家相关法律法规和制度的要求；三、满足相关主管单位和行业要求；四、合理地规避或降低风险。

高可用性系统:
可用性大于或等于99.9% ,年度停机时间小于或等于8.8小时的系统,例如,银行、证券、非银行支付机构、互联网金融等交易类系统，提供公共服务的民生类系统、工业控制类系统、云计算平台等。

---

提示：以下是本篇文章正文内容。

等保测评高风险判定——第四章 安全计算环境（应用系统）

安全计算环境（应用系统）

二级及以上系统高风险判定

1.1应用系统口令策略缺失

要求项:应对登录的用户进行身份标识和鉴别,身份标识具有唯一性,身份鉴别信息具有复杂度要求并定期更换。

解读:
应用系统无用户口令长度,复杂度校验机制,例如可设置6位以下，单个、相同、连续数字、字母或字符等易猜测的口令。

补偿措施:
1)应用系统采取多种身份鉴别、访问地址限制等技术措施，获得的口令无法直接登录应用系统，可根据实际措施效果，酌情判定风险等级；
2)对于仅内网访问的内部管理系统,可从内网管控、人员管控、实际用户口令质量等角度进行综合风险分析,根据分析结果,酌情判定风险等级；
3)对于部分专用软件、老旧系统等无法添加口令复杂度校验功能的情况,可从登录管控措施、实际用户口令质量、口令更换频率等角度进行综合风险分析,根据分析结果,酌情判定风险等级;
4)对于特定应用场景中的口令,例如PIN码、电话银行系统查询口令等，可从行业要求、行业特点等角度进行综合风险分析,根据分析结果,酌情判定风险等级。

1.2应用系统存在弱口令

要求项:应对登录的用户进行身份标识和鉴别,身份标识具有唯一性,身份鉴别信息具有复杂度要求并定期更换。

解读:
通过渗透测试或使用常用口令尝试登录,发现应用系统中存在可被登录的空口令、弱口令账户。

补偿措施:
1)对于互联网前端系统的注册用户存在弱口令的情况,可从对单个用户,整个应用系统所可能造成的影响等角度进行综合风险分析,根据分析结果,酌情判定风险等级;
2)对于因业务场景需要,无身份鉴别功能或口令强度达不到要求的应用系统,可从登录方式、物理访问控制、访问权限、其他技术防护措施、相关管理制度落实等角度进行综合风险分析,根据分析结果,酌情判定风险等级。

1.3应用系统口令暴力破解防范机制缺失

要求项:应具有登录失败处理功能﹐应配置并启用结束会话,限制非法登录次数和当登录连接超时自动退出等相关措施。
解读:
通过互联网登录的应用系统登录模块未提供有效的口令暴力破解防范机制。
补偿措施:
1)应用系统采取多种身份鉴别、访问地址限制等技术措施,获得口令无法直接登录应用系统,可根据实际措施效果,酌情判定风险等级;
2)对于互联网前端系统的注册用户,可从登录后用户获得的业务功能、账户被盗后造成的影响程度等角度进行综合风险分析,根据分析结果,酌情判定风险等级;

涉及资金交易、个人隐私﹑信息发布、重要业务操作等的前端系统,不宜降低风险等级.

3)对于无法添加登录失败处理功能的应用系统,可从登录地址、登录终端限制等角度进行综合风险分析,根据分析结果,酌情判定风险等级。

1.4 应用系统鉴别信息明文传输

要求项:当进行远程管理时﹐应采取必要措施防止鉴别信息在网络传输过程中被窃听。
解读:
应用系统的用户鉴别信息以明文方式在不可控网络环境中传输。

补偿措施:应用系统采取多种身份鉴别,访问地址限制等技术措施,获得口令无法直接登录应用系统,可根据实际措施效果,酌情判定风险等级。

1.5 应用系统默认口令未修改

要求项:应重命名或删除默认账户,修改默认账户的默认口令。
解读:
应用系统默认口令未修改,使用默认口令可以登录系统。

补偿措施:对于因业务场景需要,无法修改应用系统的默认口令的情况,可从设备登录方式、物理访问控制、访问权限、其他技术防护措施、相关管理制度落实等角度进行综合风险分析,根据分析结果,酌情判定风险等级。

1.6 应用系统访问控制机制存在缺陷

要求项:应由授权主体配置访问控制策略,访问控制策略规定主体对客体的访问规则。
解读:
应用系统访问控制策略存在缺陷,可越权访问系统功能模块或查看、操作其他用户的数据；例如存在非授权访问系统功能模块、平行权限漏洞、低权限用户越权访问高权限功能模块等。

补偿措施:
1)对于部署在可控网络环境的应用系统,可从现有的防护措施﹑用户行为监控等角度进行综合风险分析,根据分析结果,酌情判定风险等级；
2)可从非授权访问模块的重要程度,影响程度,越权访问的难度等角度进行综合风险分析，根据分析结果,酌情判定风险等级。

1.7 应用系统安全审计措施缺失

要求项:应启用安全审计功能,审计覆盖到每个用户,对重要的用户行为和重要安全事件进行审计。

解读:
1)应用系统无任何日志审计功能,无法对重要的用户行为和重要安全事件进行审计;
2)未采取其他审计措施或其他审计措施存在漏记,旁路等缺陷,无法对应用系统重要的用户行为和重要安全事件进行溯源。

全部条件都满足才可判定高风险。

补偿措施:对于日志记录不全或有审计数据但无直观展示等情况、可从审计记录内容、事件追溯范围等角度进行综合风险分析,根据分析结果,酌情判定风险等级。

1.8 应用系统审计记录不满足保护要求

要求项:应对审计记录进行保护,定期备份﹐避免受到未预期的删除,修改或覆盖等。
解读:
1)应用系统业务操作类、安全类等重要日志可被恶意删除﹑修改或覆盖等;
2)应用系统业务操作类、安全类等重要日志的留存时间不满足法律法规规定的相关要求(不少于六个月)。

任意条件满足都可判定高风险。

补偿措施:
1)对于应用系统提供历史日志删除等功能的情况,可从历史日志时间范围、追溯时效和意义等角度进行综合风险分析,根据分析结果,酌情判定风险等级;
2)对于应用系统未正式上线或上线时间不足六个月等情况,可从当前日志保存情况、日志备份策略、日志存储容量等角度进行综合风险分析,根据分析结果,酌情判定风险等级。

1.9 应用系统数据有效性检验功能缺失

要求项:应提供数据有效性检验功能,保证通过人机接口输人或通过通信接口输入的内容符合系统设定要求。
解读:
1)应用系统存在SQL注入、跨站脚本、上传漏洞等可能导致敏感数据泄露、网页篡改,服务器被入侵等安全事件的发生，造成严重后果的高危漏洞；
2)未采取 WEB应用防火墙、云盾等技术防护手段对高危漏洞进行防范。

全部条件都满足才可判定高风险。

补偿措施:对于不与互联网交互的内网系统,可从应用系统的重要程度、漏洞影响程度、漏洞利用难度、内部网络管控措施等角度进行综合风险分析,根据分析结果,酌情判定风险等级。

1.10 应用系统存在可被利用的高危漏洞

要求项:应能发现可能存在的已知漏洞,并在经过充分测试评估后,及时修补漏洞。
解读:
1)应用系统所使用的环境,框架、组件或业务功能等存在可被利用的高危漏洞或严重逻辑缺陷,可能导致敏感数据泄露,网页篡改,服务器被入侵、绕过安全验证机制非授权访问等安全事件的发生；
2)未采取其他有效技术手段对高危漏洞或逻辑缺陷进行防范。

全部条件都满足才可判定高风险。

补偿措施:
对于不与互联网交互的内网系统,可从应用系统的重要程度,漏洞影响程度,漏洞利用难度，内部网络管控措施等角度进行综合风险分析,根据分析结果,酌情判定风险等级。

三级及以上系统高风险判定

2.1应用系统未采用多种身份鉴别技术

要求项:应采用口令,密码技术、生物技术等两种或两种以上组合的鉴别技术对用户进行身份鉴别,且其中一种鉴别技术至少应使用密码技术来实现。

解读:
通过互联网登录的系统,在进行涉及大额资金交易、核心业务、关键指令等的重要操作前未使用两种或两种以上鉴别技术对用户身份进行鉴别。

补偿措施:
1)在身份鉴别过程中,多次采用同一种鉴别技术进行身份鉴别,且每次鉴别信息不相同,例如两次口令认证措施(两次口令不同),可根据实际措施效果，酌情判定风险等级；
2)在完成重要操作前的不同阶段使用不同的鉴别方式进行身份鉴别,可根据实际措施效果，酌情判定风险等级；
3)对于用户群体为互联网个人用户的情况,可从行业主管部门的要求、用户身份被滥用后对系统或个人造成的影响等角度进行综合风险分析,根据分析结果,酌情判定风险等级；
4)对于采取登录地址限制、绑定设备等其他技术手段减轻用户身份被滥用的威胁的情况,可从措施所起到的防护效果等角度进行综合风险分析,根据分析结果，酌情判定风险等级。

---

总结

以上就是今天要讲的内容，本文仅仅简单介绍了安全区域边界篇的高风险判定，如有不解和错误，欢迎大家一块讨论。

                                             FROM：MZR