图 1: 反馈和英特尔安全软件供应链的交集
原文请参见：http://www.devsecops.org/blog/2016/5/20/-security
软件由多个组件组成, 可快速满足客户需求。从构思开始，通过软件来实现价值的端到端过程, 以成品或服务结束, 从而显著改善客户的生活。一些描述软件供应链从右向左列举软件的连续交付, 因为它经过许多阶段，从设计, 通过实施, 然后构建和最终部署。软件的持续交付通常称为持续集成/持续部署 (CICD) Pipeline 的构建和部署自动化支持。此 Pipeline 用于支持快速部署和持续的反馈循环, 从而允许持续的软件改进。CICD Pipeline 使许多人能够为项目的成功做出贡献, 并每天进行快速更改以满足客户的需求和需求。
随着 Lean、敏捷 (Agile)、Scrum 和 DevOps 的引入, 存在一个左移 (shift-left)的范式, 这就要求软件支持的操作面用协作方法在供应链中更早地移动。重要的工具和流程也被迁移到更接近于平台 (如公共云), 以便更容易地在软件供应链中更早地解决这些操作上的问题。这使得有可能去除导致瓶颈和降低创新速度的过程。有些人认为安全是这一转变的最后一个前沿。这篇文章的其余部分描述了一些顶层 (top-level) 的要求以及将安全转移到左边的注意事项。
将软件供应链的操作方面迁移到左边, 可以确保这些关注点在设计上是有约束的, 因为它们代表了太多的负担、债务或复杂性。对于像我这样的安全从业者来说, 向左移动是一个完全的涅磐, 因为它代表了更早地看到更好的安全产品的机会。本质上, 安全性成为设计约束。左移模式也与消息传递相一致, 即要求将安全性内置到软件中, 而不是被接上。
联邦贸易委员会去年夏天提供了一份公开的白皮书, 讨论增加安全性的起点摘录如下:
"从一开始就考虑安全性的公司评估他们的选项, 并根据其业务的性质和所涉及的信息的敏感性做出合理的选择。对数据的威胁可能会随着时间的推移而改变, 但声音安全的基本原理仍然不变。"
FTC 白皮书列举了在其采取的 50 多项执法行动中的一些使用案例, 以产生更好的安全性, 查明这些执法行动中的 10 个共同问题。这些问题中的许多都可以转换为已编纂的安全要求和可在软件供应链中早期使用的工件。随着软件开发过程中较早的安全要求, 它还使连续交付 Pipeline 的执行部分具有改进的测试、监视和响应, 以支持安全检测。
听起来容易吗？不是的, 也有很多技术行业必须做出改变。如果我们考虑一下, 大多数的 -ilities 是设计上的约束, 通常是技术债务的原因, 那么就不难理解了。团队必须找到方法来创新和交付价值, 而不产生太多的技术债务。让我们进一步研究一下软件安全性:
通常, 安全要求是通过纸面策略和标准来描述的, up-front 然后检查软件供应链的末尾。安全文档通常是非常繁琐的操作, 它包含大量的细节, 最终使软件开发人员没有兴趣参与其中。在传统的方法中, 软件被开发出来, 随后由安全小组进行检查, 以确保在发布到生产之前获得批准。这与大多数通过检查和平衡确保利益相关者的封闭流程是一致的。由于政策和标准的复杂性, 检查通常是通过手动检查进行。由于时间限制, 如果要执行所有全覆盖的所有检查, 则时间限制会很困难。此外, 需要执行的许多检查都要求将软件发布到一个端到端环境中, 然后才能有效地验证符合上游提供的策略和标准。这最终造成了鸡和蛋的情况, 往往导致开发商和安全的关系相互损害。
那就是说, 安全可以在软件供应链中以极大的努力被向左转移。使用左移方法, 软件以安全作为设计约束和软件定义平台作为实现手段来开发。这使得实现高级测试、威胁 intel 和最终结束调查 (红色团队演习) 成为可能。更重要的是, 它创建了 更长生命周期 (longer-lived) 和更有弹性的软件。
为了有效地将安全转移到左侧, 在开始时就将安全作为代码来创建, 我们列举了一个成功程序的以下 5 元素:
理解安全反馈对于减少软件攻击和不断调整负载以抵御攻击是至关重要的。内部安全小组不是敌人。事实上, 内部安全团队有能力帮助减少传统安全工具所识别的复杂性和误报, 方法是关注具有最高攻击可能性的行为异常。毕竟, 一个 350 页的 pdf 不一定能提供 DevOps 团队需要的细节和帮助。相反, 需要一种协作和贡献价值的文化来创建更安全的软件。例如, 下面的示意图描述了安全的软件供应链和必要的反馈回路和安全功能:
图 1: 反馈和英特尔安全软件供应链的交集
制定安全设计决策的大部分工作很容易转移到 scrum 团队中的内嵌开发角色。毫无疑问, 这是迄今为止最好的解决方案, 并允许 DevOps 团队在平衡和上下文中解决安全问题。与其他设计约束一样, 这也为创建一个价值创造者的假设提供了繁重的任务。然而, 这种方法的主要缺点是缺乏足够的信息来做出明智的决定, 以便创造一个成功的假说来创建有弹性的软件。尽管它有不同之处, 但认为基于签名的静态和动态分析将提供所需的所有安全测试是不够的。安全性作为代码将加速将控件和策略转换为平台和应用程序组件。可以添加仪器来提供信号噪声。然而, 安全性并不等同于质量, 因为反模式开发可以包括非软件元素作为安全终止链的一部分和一个有动机的对手。换言之, DevOps 团队成员、他们所在的位置、他们的合作伙伴和他们信任的组件部件是他们的应用程序攻击面的一部分。
此外, DevOps 花费所有的时间试图做一个复杂的工作, 需要很大的深度工作通常会失败, 因为专家的关注点通常会下降, 因为有利于生产率、可用性或延迟。开发人员被激励去创建价值作为其工作的隐式元素。然而, 确保安全的工作是一项非常科学的工作, 从价值创造看，往往需要一套完全相反的技能。虽然一些安全工作可以嵌入到 DevOps 中, 但它通常是一个以行为分析和取证为基础的上下文绑定工作。做得好, 甚至自动化实现, 这项工作也是不平凡的。与其他上下文工作一样, 安全性通常由具有重要经验的专业人员完成。
答案是什么？文化.向左移动需要每个人都知道如何协作和理解足够的上下文, 以确保软件的安全性。团队必须认识到, 做出决定是困难的, 每个人都可以在构建伟大软件的方程式中提供一些东西。DevOps 团队建立伟大的创新和安全团队确保信任。关键的因素是带给人们和发展一套共同的测量, 每个人都可以从中学习。迭代还可以通过不过度的理想状态集来改进进入软件的所有内容, 从而避免连续协作的行为。有时简单地对一个迭代发布计划进行透明化, 并设定一个假设, 可以减少所有参与者的摩擦。例如, 如果您从一开始就无法构建完美的安全控制, 但您所构建的控件与您在项目阶段所面临的风险是相称的。真正的迭代需要在整个设计中传播, 真正使每个人都能参与 DevOps 文化。
安全性是大多数软件开发项目的一个令人关注的问题。通常, 它还代表了一组功能, 必须存在, 让客户安全舒适的使用应用程序。我们曾提到过这一点, 但更明确地指出: 开发人员为组织建立价值的地方;安全地建立信任。构建更好的安全性需要在安全软件供应链中有三主要角色: 1) 构建者、2) 实现者和 3) 破坏者。我想, 任何人都可以将安全作为代码来构建, 这样做的挑战只是协作、工具和组织。但是, 安全越来越复杂, 攻击面变得复杂, 超出了工具可以检测到的范围。同样, 攻击者使用 DevOps 使用的相同的敏捷方法和工具来提高其开发和渗透的速度。从本质上说, 这意味着良好的安全性来自于所有三关键角色的混合方法, 以便深入地防御, 并在速度和规模上保持对攻击者的领先地位。纸张上的东西才不会在不断变化的环境中切割。
在将纸张上的规则转换成代码时, 我们从马斯洛那里窃取了一页, 并创建了一个软件安全需求的层次结构。此模型背后的意图是帮助构建人员从安全角度了解最关心的问题, 以及如何使用分层方法构建控制。例如, 如果您在工作负载中生成加密, 但无法有效地对工作负载进行分区/包含, 则极有可能由于环境无法保护数据和/或加密密钥而使加密失败。同样, 在错误区域引入未经授权的不安全资源时, 具有分区但没有资源管理的环境可能会成为牺牲品。
图 2: 软件安全需求的层次结构
使用软件安全需求的层次结构, 可以将应用程序和启用平台统一起来, 实现完整的堆栈安全。应用程序从启动到运行时变得更健壮。将策略添加到每个层中, 并通过所关注的层次结构形成一些一致性。软件定义的平台被用来提供保护性控制和防御基础设施攻击的应用程序, 使它们更具弹性。然而, 这必须与应用程序和组织的需要相平衡。没有一种 fits-all 的方法来确保创新。该方法必须量身定做, 并符合组织的文化、目标和政策, 以便所有团队成员都能跨边界进行协调。正是这种程度的协调, 使得在速度和规模上提供安全、灵活的软件创新成为可能。
此外, 也没有单一的平台来帮助确保作为代码的安全性, 因为端的组件通常是使用不同的语言创建的。市场中存在着无数的保护性控制。它们引入的约束具有减少安全问题的效果, 但它们通常会造成操作模型和其他控制要求。因此, 重要的是要确保一个 fits-all 的模式而不是心态, 因为许多这些保护措施不能解决常见的错误。检查/评价控制及其偏离基线状态对于确保一般的错误不会到线上环境非常重要。堆栈的每个层中的控制并不总是兼容的, 通常不会使用相同的代码来传递。实质上, 这意味着在整个堆栈中的每个级别都需要将安全性代码化为一个控制生态系统。安全性作为代码的最低状态应包括一个清单、继承和解析回同一个组件基线, 以确保连续反馈有一个闭环。换句话说, 让每个人都工作, 并在过程中联系在一起, 使每个人都知道如何从正确的人那里迅速得到反馈。
不需要开发时间的艺术是存在的。它不是将来会消失的东西, 但可能会演变成利用持续的交付, 公共云和 DevOps 时代。攻击者仍在不断发现和利用哪怕是最小的错误和曾经解决再发现的安全缺陷。通过在软件组件和接口之间授予的信任关系, 他们可以获得访问权限并升级其权限。事实上, 小错误和不可靠的信任关系一直与灾难性后果联系在一起。因此, 对组织来说, 更重要的是投资于狂热的测试和组件检测和解决问题, 然后才能充分利用它们。同样, 重要的是, DevOps 团队要了解如何使安全资源充分受益, 以及如何理解他们在控制生态系统中的责任。以下是对支持 DevOps 的安全功能和潜在工具的持续传递生命周期的快速描述 (这是一个示例, 可能包含了数以千计的工具):
对于许多人来说, 将重点放在转换过程上, 将策略和测试包括在其连续交付 Pipeline 中是有用的。狂热的测试开始于理解需要测试的内容和方法。测试驱动开发应将安全性作为设计约束, 作为得到开发的软件的一部分逐步测试。这意味着像 OWASP 前 10 这样的应用程序安全测试应该包括在项目开始时针对软件运行的测试中。对于像跨站点脚本和 SQL 注入这样的东西来说, 如果没有一个测试无法列举攻击案例, 它就完全可以到线上环境。这实质上意味着, 在开发软件的过程中, 确保 OWASP 前 10 的工具和技能基本上需要提前移动。这也意味着, 安全专业人员应该评估所包含的测试, 以枚举攻击者将其时间用于创建关闭测试周期以实现安全的生态系统的一些模糊边缘情况。
同样, 在完全堆栈软件定义的环境中, 将等效的 OWASP 前 10 添加到一组测试方案中是至关重要的。从我们的安全需求层次来看, 最高优先级的问题是一贯的分区和爆炸半径问题、糟糕的组件管理、检测/记录的微弱尝试、身份验证/信任失败以及加密/安全管理的误用.由 Chef 和 Puppet 提供的配置管理套件有多种测试功能, 可以在连续交付的情况下减少这些问题。更强调疯狂的配置测试, 可以减少一些最臭名昭著的攻击面。
软件定义的环境还需要专业测试知识, 更强调组件/服务白名单。在不了解攻击面的情况下使用组件部件是信任攻击的好方法。使用高保真组件与生态系统的安全性是减少攻击面的重要因素。云提供商不太可能支持这种方法, 因为增加透明度和披露基于模式的弱点在很大程度上仍然是新的领域。像 CVSS、CVE 和 CWE 这样的常见漏洞机制尚未解决基于模式的攻击模型问题, 这些模式将继续从误用信任模型中浮出水面。例如, 您可
能有需要在提供者之间建立高度信任的数据, 并且错误地引入了一个组件或服务, 其信任程度低于您的体系结构足够安全所需的信任。
组件也是必不可少的, 需要被设计成一个工作负载早期的添加剂和避免制造噪音, 损害了检测和响应。在 DevSecOps 中，速度是一个关键的因素, 主要提供了组件, 相关性和属性到一个组件部分。发现和解决缺陷的速度越快, 将风险降低到最低的几率就越大。对于上下文, 组件是反馈回路的一部分，支持安全召回, 并且能消除需要时间学习和探索环境的攻击。
那么, 狂热的组件什么样子的呢？考虑一下, 您已经开发了一个攻击地图, 并且您需要的一个控制是一个警报, 以了解当其中一个安全假设受到挑战时。在这种情况下, 您可以添加日志记录或作为应用程序的一部分触发的事件, 以便在相关序列中发出警报。例如, 管理应用程序被设计为在 8-5 时可以使用，并且用户在 9pm 登录触发警报。这提供了一个基线触发器, 导致安全操作监视和评估用户的操作和行为。在许多情况下, 应用程序可能被设计为能够自我修复, 当出现这样的触发器时, 策略答案指示用例是不可接受的。
Gene Kim 在定义什么是成功的需要速度和规模的价值创造，作了了不起的工作。其中一个关键因素是基于信任的环境, DevOps 可以很容易完成任务。无可挑剔的环境价值是快速学习和适应, 或者更有启发的创新。为了帮助我们实现一个良好的环境, 让我们来看看安全, 这是臭名昭著的，因为一些受到责备的功能。责备来自试图追究某人对自己的决定和行动的责任。与此相反的是值得称道的行为。然而, 安全性很难转换, 因为在设计或开发软件之前, 确保安全的信息并不总是可用。
无可挑剔背后的现实需要转化成一个公式, 需要作出决定, 所有的权利限制前可用。安全摘要需要足够大包含一些常用的知识, OWASP, san, PCI, NIST, 和其他许多。安全专业人员贡献了这些信息, 并组织好这些资料作为自己使用。这不完全是友好的。事实上, 如果你不知道这些条款, 那么它是一个巨大的学习成本。攻击者以创造性的方式使用软件, 这些方法从来都不是软件初衷的一部分。换言之, 攻击者建立反模式和安全是一个非常复杂的发现科学。例如, 跨站点脚本已存在一段时间, 当与 kill 链的其他部分混合时, 可以减少对原始软件的信任。最初的设计者考虑过这个吗？不。然而, 跨站点脚本并不是完全直观的, 也不是软件设计者会立即考虑的, 作为他们构思和开发过程的一部分。相反, 设计师最感兴趣的是是否真的会有实际的工作。
对安全的无可指摘的转变是用尽可能多的信息尽快武装 DevOps。但是更重要的是, 一个 DevOps 的团队需要一种学习安全的方法, 这样他们就可以承担起为他们的软件做出更好的安全决策的责任。人们曾经认为, 安全问题可以转化为培训模块, 软件在开发人员进行安全的代码培训后最终会变得更好。它是等式的一部分, 但在 DevOps 团队正在进行的实际软件之外, 这些信息很难应用到晦涩和微妙的问题上。如果我们认为它是容易理解的问题, 使软件离线和更难理解的创建滥用反模式,那么我们可以更好地期待 DevOps 团队需要他们的培训和反馈循环。测量可以帮助通过树木看到森林, 它是创造一个无可指摘环境的循环的一部分。
创新的软件是通过对客户的需求做出选择, 并平衡产品的持续和成熟来进一步满足顾客的需求。一个假说需要有好的仪器和测量, 而不是责备。这意味着, 测量是一个关键的因素, 以采取科学的方法来开发软件, 并明确当安全作为一个设计的约束前。
图 4: 用于测量安全缺陷的示例
因此, 信息是巨大的, 它对 DevOps 团队来说，也是一个巨大的负担 。拥有有用和可操作的智能可以让 DevOps 团队快速识别需要立即更正的问题。 one-size-fits-all 和这种方法不匹配。解决电网自动化的软件比手游可能需要一个不同的安全策略。同样, 将这种类型的信息转化为需要纠正的安全缺陷是一门耗费时间的学问。检测事件通常需要关联其他分析来确定需要更改的内容和方式。找到一种方式来提供正确的信息平衡, 快速和快速的决议有它的优势。一些选择优先权票和其他选择安全等级。选择使您的组织更快的度量是必不可少的。在几分钟内解决问题可以是细微差别和严重违规的区别, 这取决于您的环境。您的组织所选择的完全是开发的文化和工具的一部分, 以使安全成为生态系统的一部分。
我们已经简要地谈到了减少谴责的措施, 但还有更多的情况。开发惊人技术的人也需要休息。攻击者总是利用隐形的艺术来推进他们的努力, 但是当他们无法工作时, 他们转而求助于技术来创造。设想一下, 您已经在软件定义的环境中微调了您的安全控制, 并让您知道应用程序是否受到攻击。攻击者可以通过多种方式利用这一原则, 这使得小团队很难成功地维护一个大型应用程序。规避攻击可能代价高昂。
对于传统的应用, 已经研究了这些技术, 并开发了 purpose-built 装置, 包括在网络层。改进数据中心和网络控制是在软件开发之外透明地进行的, 因为安全专业人员已经被这些类型的攻击策略淹没了多年。将工作负载从具有所有这些目的构建功能的环境中拉出, 并将其置于软件定义的环境中, 也意味着需要开发新的技术和工具。是的, 这也意味着移动安全性更接近开发的软件。安全的自然演进是从网络到主机到软件。不幸的是, 时机并不适合当前软件的发展, 这意味着许多相同的传统攻击将再次上升, 在软件定义的环境中被解决之前。
非常规攻击正在上升, 并利用 SaaS 和云服务, 因为它使攻击者能够进入在安全技术不成熟的公司和第三方之间建立的信任关系。例如,HammerToss 使用 Twitter、Github 和云存储来制定其杀伤链, 并使用一套常用的工具收集情报。数据中心安全模型要求有效负载违反并提供从防火墙后面的访问。这实质上意味着可以对安全保护和侦探控制进行调整, 以寻找一组方法。在今天的环境中, 云为攻击者提供了一种利用信任模型和密码来获取访问权限的方法, 因为边界已经转移, 环境基本上变得没有边界了。(谷歌有一个关于这个主题的伟大论文: BeyondCorp)
图 5: 鲜为人知的攻击需要持续的安全科学
更多地考虑信任边界和攻击模型可以极大地帮助减少这些新类型的非常规攻击, 但它不可能是一个常规的场景。了解和研究软件如何使用, 以通过树木看到森林是一门复杂的科学。它需要不同的角度和时间来破译正在开发或更坏用途的软件。这转换成一个安全程序, 它围绕反模式事件, 通常有助于确定在安全的软件供应链中, 他们需要纠正的地方。
最后, 左移安全程序的这五元素可以帮助您成功地进行所需的安全转换, 以支持 DevOps 和软件定义的环境。希望它能提供更多的信息, 说明一些真正的挑战是为了在速度和规模上利用安全创新而努力。安全的软件供应链需要一些非常有趣的问题要解决, 安全成为一个主要的设计约束, 而不是简单的部分发布测试。
主贴直达： https://testerhome.com/topics/11290
