最小可行安全产品是 B2B 软件和业务流程外包供应商的简约安全检查表。
设计时考虑到了简单性，清单仅包含必须实施的那些控制措施，以确保产品的安全状态最低限度。
我们建议所有构建 B2B 软件或以其他方式处理其最广泛定义下的敏感信息的公司至少实施以下控制措施，并强烈鼓励在其安全计划中远远超出这些控制措施。
1 业务控制
控制描述
1.1 漏洞报告
- 在您的网站上发布安全报告的联系人
- 在合理的时间范围内响应安全报告
1.2 客户测试
- 根据要求，让您的客户或其代表能够测试您的应用程序的安全性
- 如果非生产环境在功能上与生产环境非常相似，则在非生产环境上进行测试
- 确保非生产环境不包含生产数据
1.3 自我评估使用本文档进行年度（至少）安全自我评估
1.4 外部测试与安全供应商签约，对您的系统进行年度全面的渗透测试
1.5 培训为您的员工实施与其业务职能相关的特定角色安全培训
1.6 合规性
- 遵守与您的业务相关的所有行业安全标准，例如 PCI DSS、HITRUST、ISO27001 和 SSAE 18
- 遵守适用于您的公司和您的客户的司法管辖区的当地法律和法规，例如 GDPR、具有约束力的公司规则和标准合同条款
1.7 事件处理
- 不迟于发现后 72 小时通知您的客户有关违规的信息，不得无故拖延
- 在通知中包含以下信息：
- 相关联系人
- 漏洞的初步技术分析
- 具有合理时间表的补救计划
1.8 数据清理确保实施基于 NIST SP 800-88 或同等标准的媒体清理流程
2 应用设计控制
控制描述
2.1 单点登录使用现代和行业标准协议实现单点登录
2.2 仅HTTPS
- 将流量从 HTTP 协议（端口 80）重定向到 HTTPS（端口 443）
这不适用于旨在在未加密连接之上运行的安全协议，例如 OCSP - 使用广泛采用的 TLS 扫描工具生成清晰的扫描
- 使用includeSubdomains指令在所有页面上包含 Strict-Transport-Security 标头
2.3 内容安全政策设置最低限度的内容安全策略
2.4 密码政策如果除单点登录外还使用密码身份验证：
- 不限制可以使用的允许字符
- 不要将密码的长度限制在 64 个字符以下
- 不要使用秘密问题作为唯一的密码重置要求
- 要求对密码更改请求进行电子邮件验证
- 更改密码时除了新密码外还需要当前密码
- 根据常用密码列表或泄露的密码数据库验证新创建的密码
- 定期检查现有用户密码是否泄露
- 使用内存硬或 CPU 硬的单向散列函数以散列和加盐格式存储密码
- 对帐户访问实施适当的帐户锁定和暴力保护
2.5 安全库使用框架、模板语言或库，通过转义输出和净化输入来系统地解决实施弱点。
示例：用于数据库访问的 ORM，用于渲染 DOM 的 UI 框架
2.6 打补丁应用严重性评分为“中等”或更高的安全补丁，或确保在补丁发布后的一个月内为应用程序堆栈的所有组件提供等效的缓解措施
2.7 记录保留以下日志：
- 用户登录和退出
- 对应用程序和系统用户和对象的读、写、删除操作
- 安全设置更改（包括禁用日志记录）
- 应用程序所有者访问客户数据（访问透明）
日志必须包括用户 ID、IP 地址、有效时间戳、执行的操作类型以及此操作的对象。日志必须存储至少 30 天，并且不应包含敏感数据或负载。
2.8 备份与容灾
- 将所有数据安全备份到应用程序运行位置以外的其他位置
- 维护并定期测试灾难恢复计划
- 定期测试备份恢复
2.9 加密使用可用的加密方式来保护系统之间传输的敏感数据以及在线数据存储和备份中的静态数据
3 应用实施控制
控制描述
3.1 数据列表维护应用程序预期处理的敏感数据类型列表
3.2 数据流图维护一个最新的图表，表明敏感数据如何到达您的系统以及它最终被存储在哪里
3.3 漏洞预防培训您的开发人员并实施开发指南，以至少防止以下漏洞：
- 授权绕过。示例：从常规帐户访问其他客户的数据或管理功能
- 不安全的会话 ID。例子：Guessable token；存储在不安全位置的令牌（例如，没有设置安全和 httpOnly 标志的 cookie）
- 注射。示例：SQL 注入、NoSQL 注入、XXE、OS 命令注入
- 跨站脚本。示例：调用不安全的 JavaScript 函数、执行不安全的 DOM 操作、将用户输入回显到 HTML 中而不转义
- 跨站请求伪造。示例：接受来自不同域的带有 Origin 标头的请求
- 使用易受攻击的库。示例：使用具有已知漏洞的服务器端框架或 JavaScript 库
3.4 修复漏洞的时间在发现后 90 天内生成和部署补丁以解决严重影响安全性的应用程序漏洞。
4 运维控制
控制描述
4.1 物理访问通过确保以下控制措施到位，验证相关设施的物理安全：
- 分层周界控制和内部障碍
- 对密钥的托管访问
- 进入和退出日志
- 入侵者警报的适当响应计划
4.2 逻辑访问
- 仅限有合法需求的用户访问敏感数据。数据所有者必须授权此类访问
- 及时停用冗余帐户和过期的访问权限
- 定期审查访问以验证需要知道的
4.3 分处理商
- 在您的网站上发布可以访问客户数据的第三方公司列表
- 每年根据此基准对第三方公司进行评估