保障云原生应用安全，需尽早定义安全需求，构建安全框架如CIS Benchmark、OWASP SAMM。通过安全卫士计划、威胁建模识别风险，并融入SDLC。验证安全需求，实施漏洞管理和渗透测试。关注DevSecOps，利用AI提升安全意识和自动化水平，实现整体安全。
译自：Defining Security in Software: Frameworks, Compliance and Best Practices
作者：Karan Goenka
OWASP Top Ten Proactive Controls 2018 版本指出：“不安全的软件正在破坏我们在全球范围内的金融、医疗、国防、能源和其他关键基础设施。随着我们的数字化全球基础设施变得越来越复杂和相互关联，实现应用程序安全的难度呈指数级增长。我们再也无法容忍简单的安全问题。” 难怪列表中的第一个控制措施是定义安全需求。安全需求为正在开发的系统提供了基础，使其能够抵御以前发生的安全威胁。那么，在一个开发人员只是编写代码的世界里，我们该如何做到这一点呢？
组织通常难以识别端到端产品开发生命周期的安全接触点。更具挑战性的部分是使接触点与企业安全对组织的意义产生共鸣。例如，过多的安全接触点可能会阻止开发人员的敏捷性并减慢开发周期，而较少的接触点将/可能导致在后期阶段发现安全问题时进行修复，这可能会贵两倍。分配给安全的时间量可能会因组织内驱动安全的因素而异。例如，初创公司可能不会花费太多时间考虑安全影响，因为他们试图通过交付产品来平衡维持运营。与此同时，高度监管行业的组织可能需要遵循严格的正式流程。大多数组织都介于两者之间，并且其需求受到客户期望以及组织必须在有限可用资源下考虑的法律和 GRC（治理、风险和合规性）问题的驱动。
根据 Veritas 的说法，只有 14% 的瀑布项目在没有遇到挑战的情况下获得成功。相比之下，敏捷项目表现出更高的成功率，有 42% 的项目在没有遇到重大障碍的情况下获得成功。敏捷项目通常依赖于 DevOps，强调开发和运营团队之间的协作。这种方法侧重于大规模交付产品，同时保持价值，从而提高整体业务水平。DevOps 代表 Developer Operations，是一套实践、工具和理念，它结合了软件开发、应用程序交付和信息技术 (IT) 运营 [SANS]。这意味着完整的软件开发生命周期，在开发、运营、持续集成和部署、日志记录、监控和质量保证之间建立持续的反馈循环。因此，它增强了各个团队之间的协调和协作。正如以下部分所解释的，这个循环仍然不包括安全性。
合规性作为一种强制机制： 安全需求为应用程序提供了经过审查的安全功能的基础。与其为每个应用程序创建自定义的安全方法，不如使用标准安全需求，使开发人员可以重用安全控制和最佳实践的定义。这些经过确切审查的安全需求为已经发生的安全问题提供了解决方案。需求的存在是为了防止过去的安全失败重演。企业安全和 GRC 团队应大声疾呼创建此类需求并供所有开发团队采用。安全需求应解决身份验证、授权、网络分段、数据保护和漏洞扫描。制定这些需求的最常见框架是 CIS Benchmark、NIST-SP-800-53 和 OWASP ASVS。收集安全需求的著名方法包括：
- NIST SP 800-53：美国国家标准与技术研究院 (NIST) 特别出版物 800-53 提供了联邦信息系统和组织的安全和隐私控制目录。
- OWASP SAMM（软件保证成熟度模型）：OWASP SAMM 框架指导组织评估和改进其软件安全态势。它包括治理、设计、实施、验证和运营实践，以及具体的活动来收集和定义安全需求。
- BSIMM（软件安全构建成熟度模型）是一个基于对许多软件安全计划的观察实践的框架。它通过将组织的实践与其他组织的实践进行基准比较，帮助组织理解和改进其软件安全计划。 其他值得注意的框架包括综合轻量级应用安全流程 (CLASP)、微软的安全开发生命周期 (SDL)、安全需求工程 (SQUARE) 和安全需求工程流程 (SREP)。相关工作还强调了 BSIMM 和 OWASP SAMM 之间的区别，组织在构建安全需求时可以参考这些内容。有了这些知识，我们现在可以看看如何确定 我们需要的安全需求。
与一般系统需求一样，安全需求的编写必须是为了实现特定目标。根据 Snyk 的说法，创建合理的安全需求有几个组成部分。安全需求必须是一致的、清晰的、明确的，并且以完整、可衡量和可测试的方式陈述。刚开始的组织可能只是简单地声明软件必须安全地开发。工程师没有受到学术界的培养，这一点已经得到充分证实。五年前，Jack Cable 作为一名研究生在 哈佛商业评论 中写道，美国排名前 23 位的计算机科学学院不要求开设网络安全课程。今年早些时候，当他在 CISA 工作时，他发现没有任何改变。从根本上说，这意味着组织不能期望开发人员能够在不投资培训和指导的情况下创建安全的解决方案。
由于这是一项未使用的技能，组织有时在产品或应用程序的设计阶段收集这些需求时会面临挑战。安全需求通常仅限于身份验证、授权、网络分段和 OWASP TOP 10。但是，让适当的安全利益相关者参与进来可以揭示更广泛的必要安全措施。安全设计应考虑产品/应用程序的 CIA 三要素（保密性、完整性、可用性）。那么，创建安全 架构和设计（在安全性和企业级软件开发的快节奏之间取得平衡）的理想流程模型是什么？为了有效地收集安全需求，必须考虑以下几个因素：
- 尽早定义安全性： 在开发开始时建立基本的安全措施，将安全性集成到设计中。安全性应该是一个非功能性需求，在设计阶段的早期就要考虑。稍后添加安全性成本更高，效果更差。追溯性的安全修复可能会导致技术债务和成本增加。
- 识别当前流程差距： 在设计应用程序和产品时，安全性经常被忽视，导致出现易受攻击的软件包和风险的错误优先级排序。这些差距源于审查、评估和重新评估漏洞的不良指南以及不充分的培训和升级流程。例如 - 频繁使用易受攻击的软件包会增加被利用的可能性，给安全团队带来挫败感，并助长机构的冷漠，从而减缓缓解风险的进展。
-
让正确的利益相关者参与进来： 通过定义 需要保护的内容、应该如何保护以及针对谁来确保产品负责人和业务发起人了解威胁和风险。左移安全方法应该不仅仅涉及工程师。这将确保有足够的安全专业知识来解决：
- 现代软件由跨越云和企业网络的互连系统组成。
- 生成式人工智能和新兴技术引入了新的安全挑战，但已建立的最佳实践有限。
- 确定组织的安全目标： 根据合规性态势或安全决策，组织将制定一个高级目标，以确保通过 SDLC 实现安全性，从而为安全接触点应该存在的位置以及最佳安全架构和设计提供一些输入。
安全意识和培训： 安全意识培训的设计应旨在教育开发和运营团队的所有级别的成员了解网络安全的一般原则、可用于防范潜在威胁的可用模式以及安全策略和程序的重要性。组织中没有足够的安全培训可能会导致一些风险，例如 - 经常使用被禁止的、不鼓励的工作流程或无意中遗漏重要的安全步骤表明：
- 服务、系统或工具方面常规培训实践的差距。
- 服务、系统或工具方面糟糕的文档。
- 尽管组织不鼓励，但糟糕的指南仍然存在。
- 重新审查新流程或期望的流程不完善。
- 禁止或不鼓励的工作流程的能力限制内的能力差距。
频繁使用不期望的工作流程来完成任务：
- 增加配置错误的概率和影响。
- 试图完成行动的参与者感到困惑。
- 制度知识代替政策，阻碍合规工作。
安全卫士计划： 安全卫士计划通过影响组织行为，使其养成更好的习惯以降低整体安全风险，从而传播最佳实践意识。安全卫士巩固了开发团队中的一个重要角色，并特别关注解决方案的“安全性”。安全卫士成为开发团队中的焦点，提供来自安全架构和应用程序安全的资源。安全卫士将是志愿者，他们作为嵌入式安全代表在其团队中工作，并负责以下事项：
- 团队内部安全活动的驱动力。
- 获得安全知识/技能并与团队分享。
- 确保通过观察、报告和补救安全问题来遵循安全最佳实践。
- 与安全团队建立牢固的关系，作为他们团队之间的联络人。
威胁建模 是非常宝贵的，如果你能鼓励一个可以跟上开发进度的流程。威胁建模从攻击者的角度识别系统中的风险和差距。通常，主题专家团队会审查应用程序图、系统架构或数据流图，以促进构建更好的系统。在最基本的形式中，Adam Shostack 提出威胁模型可以简化为四个基本问题：
- 我们在做什么？
- 可能出什么问题？
- 我们打算怎么做？
- 我们做得好吗？
此活动的输出记录为系统的风险。然后测量其影响和概率以确定严重程度。然后将严重程度用于整体软件开发过程中的优先级排序。威胁建模既是艺术又是科学，因此受益于迭代方法来全面评估拟议的解决方案。组织可以使用以下步骤来执行威胁建模练习。
- 从高层次上，识别任何应解决的明显风险。
- 将应用程序/系统分解为模块化部分。在模块级别识别风险。
- 使用一个或多个风险评估模型来帮助识别其他威胁向量（例如，PASTA、STRIDE 等）
- 识别环境中的主动控制措施。这些措施是否减轻了任何已识别的风险，或者是否已识别出其他差距？列出补救措施以及如果威胁实现，已识别威胁的可能性和影响评级。可以使用标准风险指标来量化这些努力。
- 重复这些步骤，直到生成全面的威胁模型。
一旦我们有了安全需求，这些需求必须成为系统质量保证计划的一部分。
验证和确认通常可以被认为是“我们构建了正确的东西吗？”（确认）和“我们是否正确地构建了它？”（验证）。这两个简洁的问题可以以多种方式应用于安全需求：
- 我们是否为系统提出了正确的安全需求？
- 安全需求所需的实施是否合适？
漏洞管理：每个组织都有某种形式的漏洞管理，无论是核心 IT 基础设施还是整体漏洞管理，其中包括 IT、应用程序、软件、产品、网络基础设施等。在此阶段应验证安全需求和随之而来的安全加固。此阶段主要包括将不同扫描工具的输出总结为更具可操作性的见解。下面列出了一些属于此领域的区域：
- 评估和修复流程。
- 减少误报的数量。
- 为团队提供关于“他们正在运行什么？”的见解。
- 对卓越工程的渴望。
- 使用已知且经过持续审查的系统提供可重复使用的经过审查的模式。
外部扫描和渗透测试：组织可以选择创建一个漏洞披露计划，以众包应用程序安全测试，同时在报告特定漏洞时验证安全控制。 除此之外，组织还可以通过针对特定域（网络、应用程序、访问控制等）的测试来对应用程序进行第三方渗透测试，从而使用信息/输出来进一步反馈到软件开发生命周期中。
为软件开发定义整体安全性不仅仅是基于策略的方法，而且还是一个团队合作，并赢得公司内部其他团队的信任。 当安全性成为公司的座右铭和原则时，团队才会感到有能力注入相关的流程和技术，以实现一定的安全保证。 安全工程不仅仅是一个项目，而是一个组织范围内的倡议，每个团队都同样有责任实现系统组织安全作为流程的目标。 安全性必须嵌入到软件开发过程的每个阶段。 否则将产生薄弱的解决方案。
技术发展迅速，不要错过任何一集。 订阅我们的YouTube频道，观看我们所有的播客、访谈、演示等。