纪要

应用安全测评流程：进场后梳理客户系统数量用途等——根据测评表查看系统的相关配置——对B/S架构系统进行安全扫描——根据测评结果编写问题汇总

第三级安全要求

身份鉴别

a)应提供专用的登录控制模块对登录用户进行身份标识和鉴别；

本条款主要通过查看应用系统的登录方式进行判定，主要查看是否是空口令登录，若为空则判定不符合。

b)应对同一用户采用两种或两种以上组合的鉴别技术实现用户身份鉴别；

三级要求对于二级多了本条款的双因子认证，需要对应用系统的使用人员进行除用户名密码方式外再多一种认证方式，比如动态口令，短信验证码等，不仅是管理员，普通用户也需要。

c)应提供用户身份标识唯一和鉴别信息复杂度检查功能，保证应用系统中不存在重复用户身份标识，身份鉴别信息不易被冒用；

本条款需要了解查看应用系统的密码配置中是否有强制措施，比如查看应用系统的配置中是否有对密码复杂度要求等配置；当均没有时判定不符合；当配置与实际使用情况不符合时，比如没有密码复杂度等配置，但实际使用的密码符合密码复杂度要求，且定期更换时，可判定此条款不符合，风险降低。主要考察口令的使用要求是否符合规范，且是否通过强制措施保证。

d)应提供登录失败处理功能，可采取结束会话、限制非法登录次数和自动退出等措施；

通过查看、询问等方式了解应用系统是否配置了登录失败处理措施，是不处理，或者自动退出，或锁定账户多久；若有相关措施则判定符合，没有判定不符合。

e)应启用身份鉴别、用户身份标识唯一性检查、用户身份鉴别信息复杂度检查以及登录失败处理功能，并根据安全策略配置相关参数。

主要查看应用系统是否允许拥有同名用户，其他的要求与以上相重复。

访问控制

a)应提供访问控制功能，依据安全策略控制用户对文件、数据库表等客体的访问；

本条款主要考察是否依据安全策略控制每个用户的访问，主要是查看不同用户是否会配置不同权限。

b)访问控制的覆盖范围应包括与资源访问相关的主体、客体及它们之间的操作；

本条款主要考察访问控制的策略是否覆盖到具体的操作，如谁能管理哪些账户仅能操作哪些类型数据。

c)应由授权主体配置访问控制策略，并严格限制默认账户的访问权限；

本条款主要考察是否有管理员去给普通用户分配权限，而不是用户自己分配或无法分配；且应限制系统默认账户的权限。

d)应授予不同账户为完成各自承担任务所需的最小权限，并在它们之间形成相互制约的关系。

本条款主要考察应用系统的管理账户是否根据管理员的担任角色来分配，有且仅有有对应的权限，比如审计员进分配审计权限，操作员进分配操作权限，且这两个角色需要由不同的人员来担任；若未分配不同权限账户，未由不同人员担任相应角色，均判定不符合。

e)应具有对重要信息资源设置敏感标记的功能；

应用安全中本条款和下条款至今未能理解，目前的理解为：应用系统上的某些敏感数据，需要模糊处理（比如打星号），或者低权限用户无法访问敏感级别高的数据。

f)应依据安全策略严格控制用户对有敏感标记重要信息资源的操作；

接上条，初步理解为：客户需要拟定相关安全策略，限制客户对敏感信息的操作，比如普通用户仅能查看，或者查看部分信息，应有个标准分类不同用户。

安全审计

a)应提供覆盖到每个用户的安全审计功能，对应用系统重要安全事件进行审计；

本条款主要考察应用系统本身是否有审计功能，审计了哪些重要事件；若客户部署了第三方审计工具，需要记录该工具的名称功能等。

b)应保证无法单独中断审计进程，无法删除、修改或覆盖审计记录；

本条款主要考察应用系统的审计进程能否被中断，当时的时候判断日志记录能否被删除，不能则算符合。

c)审计记录的内容至少应包括事件的日期、时间、发起者信息、类型、描述和结果等；

本条款主要考察审计的记录是否全面，概括来说就是需要审计到哪个账户在什么时间点干了什么事，操作结果如何；若客户部署了第三方审计工具，需要记录该工具审计记录包含哪些内容。

d)应提供对审计记录数据进行统计、查询、分析及生成审计报表的功能；

本条款主要考察应用系统的审计功能是否能生成类似柱状饼图的图表，以便发生安全威胁溯源时进行分析。

剩余信息保护

a)应保证用户鉴别信息所在的存储空间被释放或再分配给其他用户前得到完全清除，无论这些信息是存放在硬盘上还是在内存中；

本条款主要考察能否发现并利用历史用户所产生的的数据；主要通过登录系统时是否会留下上一用户信息进行判别。

b)应保证系统内的文件、目录和数据库记录等资源所在的存储空间被释放或重新分配给其他用户前得到完全清除。

本条款主要考察能否发现并利用历史用户所产生的的数据；笔主实习的时候别的项目经理是说根据主机安全的这一项来判断应用安全的符不符合，一致即可；Windows主要查看本地策略中的安全选项“关机前清除虚拟内存页面”和“用可还原的加密来存储密码”是否启用；linux系统通过查看历史文件判别是否符合。

通信完整性

应采用密码技术保证通信过程中数据的完整性。

本条款主要考察应用系统通信过程中数据的完整性，如是否有MD5校验等功能。

通信保密性

a)在通信双方建立连接之前，应用系统应利用密码技术进行会话初始化验证；

本条款主要考察应用系统会话初始化验证；B/S架构下需要采用HTTPS，C/S架构需要询问开发者是否拥有相关算法保证。

b)应对通信过程中的整个报文或会话过程进行加密。

本条款主要考察应用系统的通信会话和报文是否加密；B/S架构下需要采用HTTPS，C/S架构需要询问开发者是否拥有相关算法保证。

抗抵赖

a)应具有在请求的情况下为数据原发者或接收者提供数据原发证据的功能；

本条款主要考察对应用系统的抗抵赖功能，笔主实习时，培训老师说如果日志里证明里原发数据，本条即可判符合。

b)应具有在请求的情况下为数据原发者或接收者提供数据接收证据的功能。

本条款主要考察对应用系统的抗抵赖功能，笔主实习时，培训老师说如果日志里证明里接收数据，本条即可判符合。

软件容错

a)应提供数据有效性检验功能，保证通过人机接口输入或通过通信接口输入的数据格式或长度符合系统设定要求；

本条款主要考察应用系统是否拥有接口数据校验功能，如只能输入多少长度以内，只能输入数字等措施。

b)应提供自动保护功能，当故障发生时自动保护当前所有状态，保证系统能够进行恢复。

本条款主要考察是否应用系统是否拥有自动保护功能；当故障发生时自动保护当前所有状态，保证系统能够进行恢复。

资源控制

a)当应用系统的通信双方中的一方在一段时间内未作任何响应，另一方应能够自动结束会话；

本条款主要考察应用系统的超时会话退出功能，一段时间内未作任何响应，另一方应能够自动结束会话

b)应能够对系统的最大并发会话连接数进行限制；

本条款主要考察应用系统的会话并发限制，限制最大并发数，避免资源消耗过多或滥用。

c)应能够对单个账户的多重并发会话进行限制；

本条款主要考察应用系统的单个账户的多重并发会话进行限制，避免内部操作风险。

d)应能够对一个时间段内可能的并发会话连接数进行限制；

本条款主要考察应用系统是否对一个时间段内可能的并发会话连接数进行限制，其实和条款b差不多，只不过限定了某个时间段，资源控制的一种手段吧。

e)应能够对一个访问账户或一个请求进程占用的资源分配最大限额和最小限额；

本条款主要考察应用系统的资源管理能力，避免单个用户或请求占用大量资源影响他人的正常使用。

f)应能够对系统服务水平降低到预先规定的最小值进行检测和报警；

本条款主要考察应用系统的监控能力，是否具备监控能力以便发生资源不足等情况进行报警处理。

g)应提供服务优先级设定功能，并在安装后根据安全策略设定访问账户或请求进程的优先级，根据优先级分配系统资源。

本条款主要考察应用系统当资源不足二仍有许多正常用户时，管理员账户能否正常访问使用，即资源优先分配给高优先级或高权限用户。