在CNAS软件检测领域，GB/T 25000.51-2016《系统与软件工程系统与软件质量要求和评价（SQuaRE）第51部分：就绪可用软件产品（RUSP）的质量要求和测试细则》是当前国内针对就绪可用软件产品（RUSP）的核心检测标准。该标准对软件的信息安全性提出了明确要求，为安全性测试提供了指导。
根据GB/T 25000.51-2016标准中第5.1.10条“产品质量-信息安全性”的规定：
适用时，产品说明应根据GB/T 25000.10-2016包含有关信息安全性的陈述，要考虑保密性、完整性、抗抵赖性、可核查性、真实性以及信息安全性的依从性，并以书面形式展示可验证的依从性依据。
具体而言，该标准要求对软件信息安全性的测试方法及要求，应参照GB/T 25000.10-2016《系统与软件工程系统与软件质量要求和评价（SQuaRE）第10部分：系统与软件质量模型》进行。GB/T 25000.10-2016将软件的信息安全性主要划分为以下关键特性：
保密性：确保信息不被未授权访问。
完整性：保护信息的准确性和完备性，防止未授权篡改。
抗抵赖性：确保用户无法否认已执行的操作或交易。
可核查性：能够追踪和验证用户操作或事件的能力。
真实性：确认用户或系统身份的真实性。
信息安全的依从性：遵循相关安全策略、法规和标准的要求。
保密性条款：产品或系统确保数据只有在被授权时才能被访问的程度
保密性核心要求解析：
保密性旨在确保数据仅能被授权方访问。这包含两个关键层面：
防止未授权访问：严格阻止未获授权的人员或系统接触相关信息或数据。
保障授权访问：确保获得授权的人员或系统能够顺畅访问其权限范围内的信息或数据。
关键实现措施：
传输过程加密：为防止数据在传输过程中被窃听，必须对整个通信报文或会话进行加密。例如，在交易系统中，涉及银行账号、交易明细、身份证号、手机号等敏感信息时，必须保障其传输安全。可采用强加密算法（如3DES,AES,IDEA等）实现。
存储过程保密：必须保证敏感信息在存储状态下的保密性。
严格的访问控制：
启用访问控制功能，基于安全策略和用户角色设置访问控制矩阵，精确管理用户对信息或数据的访问权限。
遵循“最小权限原则”：授予账户执行任务所必需的最低权限。例如，管理员账号仅拥有管理权限，不应具备业务操作权限。
建立账号间相互制约关系：例如，审计人员不应拥有系统管理权限，系统管理人员也不应拥有审计权限，以此形成角色间的有效制衡。
保密性测试重点：
测试工程师在验证软件保密性时，应着重检测以下方面：
a.权限分配合理性：检查是否存在垂直越权（低权限用户获取高权限）或水平越权（同级用户访问非授权数据）漏洞。
b.通信会话加密：验证敏感数据传输是否采用安全协议（如HTTPS）进行加密保护。
c.加密算法强度：评估使用的加密算法是否足够安全，避免采用弱加密算法
d.敏感信息泄露风险：检测用户信息、敏感数据等是否存在泄露途径或隐患。
完整性条款：产品、系统或组件防止未授权访问、篡改计算机程序或数据的完整度
完整性核心要求解析：
完整性旨在防止数据在传输和存储过程中遭受破坏或篡改。
关键保障措施：
数据完整性校验：
在数据传输或存储过程中，通常采用增加校验位、循环冗余校验（CRC）等方式，用于检测数据完整性是否被破坏。
在通信过程中，可采用散列运算（如SHA-256）和数字签名等技术来确保数据的完整性。
数据库层面的完整性保护：
采用关系型数据库（如Oracle）存储数据。
通过设置数据库约束（如唯一键约束、检查约束（实现可选值控制）、外键约束等）来增强数据完整性。
利用数据库事务机制保证操作的原子性，避免因操作中断或回滚导致的数据不一致，从而保护完整性。
完整性测试重点：
测试工程师在验证软件完整性时，应着重检测以下方面：
a.数据操作校验：检查系统软件在执行数据增加、删除、修改操作时，是否对输入数据的格式、范围、有效性进行了严格的校验。
b.数据库架构与约束：评估数据库架构设计的合理性，并检查数据库完整性约束条件（如唯一键、检查约束、外键等）的设置是否恰当有效。
抗抵赖性条款：活动或事件发生后可以被证实且不可被否认的程度
抗抵赖性核心要求解析：
抗抵赖性旨在为关键操作提供不可否认的证据。
关键实现措施：
安全审计与日志管理：
启用安全审计功能，对系统活动或事件进行追踪记录。
对生成的审计日志进行严格管理，确保日志内容不能被任何人修改或删除，以此形成完整的证据链。
数字签名应用：
在处理重要事务时采用数字签名技术。
在收到相关请求的情况下，数字签名应为数据的原发者或接收者提供关于数据原发和数据接收的可靠证据。
抗抵赖性测试重点：
测试工程师在验证软件抗抵赖性时，应着重检测以下方面：
a.审计日志机制：检查软件系统后台是否具有日志记录机制，并评估日志内容是否详细记录了关键操作（如用户行为、系统事件）。
b.会话标识管理：检查系统会话处理机制是否有效（例如，对Cookie、Session、Token等会话标识的管理是否安全可靠，能否防止伪造或劫持，确保操作可追踪到特定用户）。
可核查性条款：实体的活动可以被唯一的追溯到该实体的程度
可核查性核心要求解析：
可核查性强调对系统内实体（如用户、进程）行为的追溯能力，其关注点与抗抵赖性有所不同，重点在于追溯的广度和深度。
关键实现措施：
全面的安全审计：
启用安全审计功能，其有效性需考察两点：
覆盖广度：审计功能应覆盖多少用户的活动。
覆盖深度：审计功能应覆盖何种程度（范围）的安全事件。
用户活动日志记录必须覆盖到每个用户，且日志内容至少应包含：
事件日期
事件本身
发起者信息
事件类型
事件描述
事件结束状态
可靠的审计跟踪管理：
审计跟踪设置必须定义存储极限的阈值（例如日志存储空间上限）。
当审计存储空间耗尽时，系统必须能采取必要的保护措施，例如：
触发报警并自动导出审计日志
丢弃尚未记录的审计信息
暂停审计功能
覆盖最旧的审计记录
可核查性测试重点：
测试工程师在验证软件可核查性时，应着重检测以下方面：
a.日志详实度与溯源能力：检查软件日志内容记录是否详细（包含前述必备要素），并评估其是否足以支持溯源（清晰关联到具体实体和行为）。
b.日志覆盖完整性：评估软件日志覆盖内容是否齐全（例如，不仅记录ERROR级别错误，还应覆盖关键操作、登录登出、配置变更等必要事件），避免常见问题（如仅记录错误）。
c.日志保留策略：检查日志保存周期设置是否合理（满足合规和溯源需求），并评估日志备份方法（如备份频率、存储位置、安全性）是否恰当可靠。
真实性条款：对象或资源的身份标识能够被证实符合其声明的程度
真实性核心要求解析：
真实性旨在确保系统能够准确验证用户身份，并确认其身份与其声明的相符程度。
关键实现措施：
专用的身份标识与鉴别：
系统必须提供专用的登录模块。
该模块负责对登录用户进行身份标识和鉴别，验证其身份的真实性，并证实其身份符合其声明的程度。
严格的凭证管理：
用户身份标识唯一性：系统中用户名必须唯一且与用户一一对应，不存在重复的用户身份标识。
强身份鉴别：采用用户名和口令方式对用户进行身份鉴别。
口令复杂度要求：提高用户口令开启复杂度，例如：
口令长度8位以上。
口令至少包含数字、大小写字母、特殊字符中的三种。
口令生命周期管理：强制定期更换口令。
账户独特性：系统不存在共享账户。
登录失败处理：
提供登录失败处理功能。
失败处理应采取有效措施，例如：
结束会话。
限制非法登录次数。
自动退出。
文档化要求：上述所有身份鉴别、凭证管理和登录失败处理的要求均应在用户文档集中明确进行规定。
真实性测试重点：
测试工程师在验证软件真实性时，应着重检测以下方面：
a.身份鉴别机制存在性：检查软件系统是否具有有效的身份鉴别机制（例如：登录、退出、单点登录等）。
b.验证码机制：评估软件系统是否具有验证码机制，并检查其验证码复杂度是否合理以及有无有效的验证机制。
c.密码策略：检查软件系统对用户设置密码是否有要求（特别是长度和复杂度要求），以及是否定期要求用户更换密码。
d.会话管理约束：检查软件系统针对Session会话中断、用户不活动后的自动退出等场景，是否设置了有效的约束机制。
e.防暴力破解机制：检查软件系统是否拥有限制登录次数的机制（如账户锁定或延迟响应），防止暴力破解攻击。
依从性条款：产品或系统遵循与信息安全性相关的标准、约定或法律法规以及类似规定的程度。
信息安全依从性核心要求解析：
信息安全依从性关注产品是否符合声明的或适用的信息安全规范。
符合性判定方法：
检查产品说明声明：
首先，审查产品说明（如用户手册、宣传资料）是否提及其遵循的信息安全相关标准、约定或法规要求。
若提及：
需审查其是否提供了相应的证明材料（如合规性证书、检测报告）。
若材料充分，则认可其声明。
若未提及，或提及但无证明材料：
则需要实际验证软件产品是否满足其自身需求文档（通常指需求规格说明书）中明确规定的信息安全要求。
依从性测试重点：
测试工程师在验证软件信息安全依从性时，可以着重关注以下方面：
a.需求文档中的安全要求：检查软件系统的需求说明书中是否明确包含了信息安全性相关的具体要求和约束。例如：
要求系统避免出现OWASP TOP 10安全漏洞。
要求进行渗透测试。
其他明确的安全目标或标准符合性要求。
b.行业特定合规性：识别并判断该软件系统的类型，是否属于金融、测绘、电力等特殊行业应用。对于特殊行业软件，必须额外关注并验证其是否满足该行业特有的信息安全法规、标准或要求。
