构建安全计划 提升应用程序安全能力

作者：科技首席科学家 Sammy Migues

目前，应用程序漏洞仍然是网络攻击最常见的攻击载体。企业必须有一个角色或团队管理应用程序安全。

新思科技认为首席信息安全官（ CISO ）在软件安全方面发挥着关键作用。

首席信息安全官（ CISO ）在软件安全方面发挥着关键作用。每家企业都需要一位有权对数据和软件组合进行治理的人员，并且他有明确的执行计划，这样有助于针对企业风险进行探讨。

IT 和软件工程企业可能需要创建基础架构、设置访问控制、创建自定义应用程序以及配置环境以抵御攻击和保护数据。但是他们要怎么确定 “ 安全 ” 意味着什么？如何做到安全？以及他们是否在实现安全？这些都是未知数。 “ 如何保障安全 ” 的标杆必须来自代表业务的人， CISO 是一个很好的选择。找到合适的人并为了他们的成功创造条件是提高软件安全能力水平的第一步。

请注意，我在这里用的是“软件”而不是“应用程序”。

当企业专注于“应用程序”时，他们往往会忘记所有框架、库、 API 、微服务、开源和其它软件组件。这些组件可能不止存在于最终包含它们的应用程序里。有时同一款软件，企业得担心数十次甚至数百次，因为，例如，相同的框架嵌入在许多应用程序中。此外，仅在应用程序级别考虑软件出处通常会模糊所有组件的来源 – 开源、定制软件以及其它所有组件。如果你不知道自己拥有什么，就无法做出有效的风险管理决策。

了解生产软件的所有组件，包括在构建时引入的组件，是软件安全能力的基础部分。除了资源充足的 CISO 和出色的软件库存之外，还有一些可信的软件安全功能的基础部分：

• Ÿ    验证企业软件开发生命周期 (SDLC) 中安全依从性的方法。 这不仅仅是对安全缺陷的测试，还必须包括遵守所有标准和策略；
• Ÿ    说到这一点， 企业将需要面向软件和数据安全的策略和标准。 这些必须是不可协商的，其中不遵守策略和标准自动会被认定是安全问题，尽管异常过程可能允许安全小组有一些额外的时间来解决；
• Ÿ    给软件安全风险排名 ，可以在时间、人力或者资金有限的时候确定重点应放在哪里？
• Ÿ    对软件项目进行排名 （改变加密算法的开发最小迭代周期可能比改变 UI 字体和颜色的开发最小迭代周期更值得仔细研究）
• Ÿ    工程师需要一个明确的联系人来解决安全问题，并让他们了解安全责任。无论你将这些人称为软件安全卫星、忍者、安全冠军还是其他，他们都需要存在。

许多企业都有正式的软件安全计划（ SSI ），这些计划已经将他们从 “ 渗透和修补 ” 的心态转变为积极主动和可信的方法。在 CI / CD 和 DevOps 之前提高软件安全能力水平不会在一天内发生，但并不复杂。

SSI 自 21 世纪初就已经出现了，与部署 SSI 的开发企业同步发展。软件安全团队经常实施耗时的测试，而工程团队瀑布式和敏捷级别流程大多数情况下都有足够的时间可以实现这些测试。这两个团队通常协调得很顺畅，每个团队都能充分发挥自己的工作，即使效率不高。软件安全能力通常关注测试过程可以找到多少错误。这对于那些执行治理和降低风险的人员来说是有效的，但却给工程人员带来了不可接受的摩擦，他们需要注重速度。

为什么摩擦像是一夜之间发生了变化？

自 2014 年左右开始，软件工程开始迅速发展。当然，敏捷、 CI / CD 和 DevOps 概念已存在多年，但它们最近才在许多企业里获得青睐。在 CI / CD 和 DevOps 后（可能伴随着仓促地对云迁移和云原生的开发），提高企业软件安全能力并不意味着使用传统的安全测试 工具 和新的工程流程。相反，它意味着与工程紧密结合，以提供节奏友好的 CI / CD 工具和文化友好的 DevOps 流程；这意味着多年来我们所讲、所学的 SSI 的 “ 安全 ” ，并使其适合 CI / CD 和 DevOps ，以创建企业自己的 DevSecOps 版本。（如果也有人告诉你 DevSecOps 意味着特定的事情以特定的方式完成，不要相信。他们试图向你推销一些东西。）卓越的 DevSecOps 确实提高了任何企业的软件安全能力水平。

当然， SSI 仍需要坚实的基础。还记得我们之前谈过的软件库存吗？那么，当编排被提出，并拆除基于基础架构即代码自动化的容器和虚拟机时，你的库存流程是否仍然有效？如何在 SDLC 中检测是否正确使用了所需的框架和 API ？

对我们已知有了缺陷的软件进行渗透测试是没有意义的，因为它的设计或构建很差，可以在软件开发的早期检测和解决。事实上，在发布之前进行安全测试需要随着时间的推移而降低价值。每个企业都必须能够设置软件安全标准，并在不遵循时该标准时能够立即提示确认。

那些负责软件安全的人必须考虑将他们的软件需求纳入待办事项，并将流程和合规性要求纳入验收标准。例如，将非功能性安全需求纳入到开发过程中，以便架构师、开发人员、测试人员和操作团队都知道应用程序的预期行为。除了一些软件安全 SMEs 之外，这些还可以在整个开发工具链和操作环境中创建传感器（测试），以确保软件符合要求。这意味着安全测试能力成为一个验证步骤，确保所有软件安全流程都能达到正确的规范，而不是耗费时间尽快找到最严重的安全缺陷并希望获得最佳的安全。

使用 CI / CD 和 DevOps ，每家企业都必须建立良好的可观察性，这是我们如何在给定状态或输出的情况下推断系统或过程的内部状态。负责治理的人需要深入了解所有正在运行的软件 – 包括容器、虚拟机和其它集成软件 – 及其行为。这一切并没有黑匣子。根据非功能性安全要求和发布验收标准，精准的传感器进行调整，告诉每个用户软件何时行为不当，并且相关人员可以立即确定它是否是缺陷、攻击或其它。

如果 CISO 不采取主动措施，他们的公司将极可能陷入各种各样的无效非生产性的工作中。公司将有负责打通云端管道的影子 IT 团队；创建使 CI/CD 各种工具相互通信的 “ 黏合代码 “ 的影子开发团队 . ；制定可行的但不安全的云设计的影子构架团队，诸如此类。一旦投入使用，那些功能正常的、创收的应用程序，如果只是没有通过任何安全检测，则极可能是无法解除的。

每家公司都要求确保 CISO 能够快速部署可接受的安全软件，无论他们是否能够在每天的每一分钟都看到每个 SDLC 的每个环节。

“ 我需要保证软件组合在任何特定时间都是适当的安全 ” 是一个明显更成熟的管理主张，而不是 “ 我必须在该软件开发结束时对其进行测试。 ”

所有利益相关者合作以便每个人步调一致和共同提高所有人的最大能力。