管理 OWASP 十大风险
作为我们安全计划的一部分，风险管理至关重要。
OWASP Top 10 列表总结了影响应用程序的最常见风险，因此是展示我们在确保解决方案安全方面所做努力的一个很好的起点。
预防漏洞和减少影响
- 我们的 "安全 SDLC "中的一些要素并非针对以下风险，而是针对一般的安全问题。
- 开发人员有机会并有时间参加安全编码培训。这些培训非常实用，旨在提供查找和修复代码中安全问题的实践经验。
- 我们的内部《编码安全标准》和《安全设计原则》是一份安全要求清单，也是所有代码必须遵守的规则清单。静态扫描有助于发现弱点和漏洞。
- 我们定期对应用程序进行内部渗透测试，以便在代码进入生产服务器之前发现潜在问题。
- 通过在技术堆栈的每个可能级别上实施最小权限原则，降低漏洞被利用的影响。
OWASP 十大风险
损坏的门禁系统
所有访问均由我们的后台系统根据必要的数据（包括调用者身份、调用端点和请求参数）进行授权，以防止纵向和横向权限升级。访问控制解决方案尽可能重复使用。与身份验证相关的应用程序接口调用都有速率限制，以降低 DoS 和自动数据采集的风险。
加密失败
网络客户端或最新设备与我们的服务器之间的任何连接始终支持 TLS。这包括从客户端浏览器到我们网络服务器的连接，也包括从设备到我们服务的连接。除非客户对设备通信有特殊要求，否则不会在传输敏感数据的设备上使用明文协议进行设备通信。
加密算法和密钥强度会定期审查并在必要时更新。
我们 SQL 数据库中的静态数据存储在加密卷中。
注射
作为防范注入式漏洞的第一道防线，我们的网络应用程序实施了输入验证。在可行的情况下，会对用户输入的类型和格式进行验证。
现代框架还提供适当的编码，以防止在创建某些对象（包括 XML 文档）时发生注入，从而降低此类漏洞的风险。
正确使用 ORM 可进一步大幅降低 SQL 注入的风险。
操作系统命令注入的风险也因基于 Java 的底层技术堆栈而大大降低。
关于 XSS，我们会手动检查我们的代码和测试环境是否存在跨站脚本。我们使用的一些技术和框架通过默认应用适当的编码来帮助防止 XSS。
不安全的设计
我们的内部《编码安全标准》和《安全设计原则》是一份安全要求清单，也是所有代码和架构必须遵守的规则清单。在对可能的改进进行决策时，我们会考虑包括 BSIMM 和 SAMM 在内的各种来源。我们的安全委员会负责管理和监督安全设计。
安全配置错误
我们的目标是在技术堆栈的各个层面实施最小特权原则。我们只安装必要的组件，从而减少了攻击面。服务器配置由自动解决方案管理，以确保符合内部政策。应用程序级配置也是自动管理的，并通过安全代码审查和静态分析进行检查。
对于 XML 处理，尽可能禁用内联 DTD 处理，或在必要时采用适当的缓解措施。
脆弱和过时的组件
我们审查第三方组件及其漏洞。对存在漏洞的组件进行评估，如果漏洞影响到我们的服务，则根据风险安排更新或修复。如果是开源组件，还可通过 GitHub 上的漏洞组件通知进行支持。此外，我们还定期进行网络扫描，以便在我们的环境中发现易受攻击的服务。
识别和认证失败
根据 NIST 建议 (NIST 800-63-3)，我们的网络应用程序要求使用强密码。
在多次尝试登录失败后，账户会被锁定，锁定时间呈指数增长。成功和失败的登录尝试都会被记录下来。密码恢复通过电子邮件进行，只发送令牌。密码从不通过电子邮件发送。数据库中的密码会使用适当的密钥推导函数（而不是普通的加密散列）进行散列，并使用标准的、众所周知的实现方式。这样即使在已知的密码散列列表上也能防止暴力攻击。
软件和数据完整性故障
我们的网络服务通过可信的、经过审核的 CI 管道进行更新。第三方模块漏洞通过 GitHub 提供的部分自动化功能进行检查。设备使用签名固件更新，不加载未签名或不可信的镜像。固件只能通过严格、精心设计的流程进行签名，以充分保护签名密钥。
日志记录和监控不足
记录可审计事件，并将日志实时收集到中央存储库中。提供审计跟踪。我们对应用程序进行监控，以检测异常情况。日志记录绝不包含机密，并且符合 GDPR 标准。
服务器端请求伪造
开发人员了解 SSRF，代码审查和静态扫描有助于防止此类问题。必要时会对用户输入进行消毒，以减少 SSRF。专门测试类似问题也是我们渗透测试的一部分。