![]()
在与数百家（也可能早过了千家）甲方企业接触后，我们发现企业的信息安全治理水平，直接取决于安全团队人员的技术专业度，而非运营经验值。所谓的技术，并非指渗透和挖洞的能力，而是指软件开发、IT 架构、网络拓扑相关的知识和经验。站在乙方的角度来看，技术薄弱的甲方安全人员，通常面临着较大的沟通障碍和成本，因为他们难以理解和区分不同安全技术和产品之间的差异。更难以理解自身企业的 IT 和技术现状，无法做出有效且大胆的决策，通常容易被大品牌厂商引导或者选择尽量不作为以此求稳。最终在各方妥协和博弈之下，做出花大钱，成效较差的短期决策。而这些决策，往往在其后继者上任之时，予以推翻。
相反，拥有较强技术背景的安全团队，非常明确知道自己想要什么，不会被厂商引导，相对不在意厂商在“付费安全排行榜”中的名次。在企业内部面对业务团队的挑战时，通常也能占有主动权，做出正向的决策，既帮助企业省钱，也帮助企业打下长治久安的基础。
网络安全从依赖于承诺（如供应商对其产品安全性的承诺），转向依赖于实际证据（如通过测试和验证获得的安全性证明），这一转变是信息技术（IT）发展的一个部分。当我谈到网络安全的成熟时，我主要指的是改变我们处理安全的方式。直到最近，我们还将其视为一个特性，并假设安全是一个工具问题：如果你从头部供应商那里购买了“正确”的、“下一代”的安全产品，你就会“安全”。现在，在经历了多年这种做法未能兑现其承诺之后，我们开始认识到，安全是一个过程，而不是一个特性。我们正在形成一种系统性的信念，即我们需要回归基础：将安全数据集中到一个地方，了解我们的环境中发生了什么，学习构成我们组织正常业务实践的因素以及可能表明已被入侵的迹象，确定如何检测恶意行为，并做出适当的响应，成熟的网络安全团队不再寻求启用后就能激活不可穿透保护盾的小工具。构建安全态势的最佳方式是基于可以观察、测试和增强的控制措施和基础设施之上。它不是建立在必须表面接受的供应商承诺之上的。这意味着你应该确切知道你受到保护的恶意活动和行为，并且能够测试和证明这一点。这也意味着，如果你能描述出想要检测和预防的事项，你应该能够在没有供应商干预的情况下单方面应用它。例如，如果一名安全工程师阅读了有关 WannaCry 的信息，他们应该有能力创建自己的检测逻辑，而无需等待一两天直到他们的供应商发布新版本。另一个正在改变安全实施方式的因素是过去十年我们见证的 IT 演变。曾经有一段时间，拥有 IT 背景足以开始作为安全专业人士的职业生涯，因为这会提供对基础设施不同组成部分如何工作、相互作用以及如何保障它们的基本理解。然而，IT 的自动化和云技术的兴起正在使后台发生的事情变得抽象化，这使得围绕 IT 基础设施开发心理模型并理解如何保障其安全性变得更加困难。要在这个时代成功地从事安全工作，一个人需要理解本地部署的基础设施、云计算基础设施的各种组件，以及基础设施，代码和 DevOps 流水线等。随着 IT 变得越来越复杂，对负责维护、管理和理解这种复杂性的人的要求也在增加。网络安全起源于黑客圈，一群对逆向工程产品和工具、动手实验以及攻破被认为无法攻破的系统充满好奇的技术爱好者之中。随后，几家安全供应商介入，承诺提供安全保障，称“当发生不良事件时我们会提醒您，只需有人检查这些警报即可”。被这种简单性的前景所吸引，我们开始聘请安全分析师来监控警报。如今，大约十年后，我们看到我们必须回到基础。显然，这种观点是一种过度简化，但事实是我们需要让黑客重新回到行业中来。未来的网络安全将非常类似于软件工程。
软件开发为我们提供了一个很好的模型：业务分析师和产品经理在业务和技术之间运作，他们与客户交谈，理解和评估业务需求，将这些需求转化为技术要求，并为开发优先排序这些需求。我经常听到有人指责安全团队不与客户交流，不够了解业务。虽然这种情绪是可以理解的，但我认为发表这些言论的人忽略了重点：批评技术安全专业人员不了解业务，就像批评后端工程师不擅长进行用户访谈一样。事实很简单：如果后端工程师想做用户访谈，他们就不会选择后端，而是会成为用户体验设计师。
我们确实需要安全团队更好地理解业务，对此毫无疑问。但我们不能通过让 IT 和安全领域的每个人都去开始采访公司内部的员工来解决问题。
软件工程提供了一套强大的工具、概念、原则和思维模型，这些将共享明日的网络安全。首先，未来的安全将是代码化的安全。现在我们有了所有的一切都是代码的形式——策略即代码、基础设施即代码、隐私即代码、检测即代码等——我们能够部署、跟踪和测试组织安全态势的变化，并根据需要回滚这些变化。反过来，这意味着一种可以测试和验证的方法，进一步巩固了基于证据的安全的观点。类似于软件工程中的工作方式，你现在可以运行自动化的安全测试以查看你的系统将如何表现，并雇用质量保证人员（比如渗透测试员）超越自动化，寻找未被自动化覆盖的边缘案例。其次，未来的网络安全将以持续监控、持续部署和频繁迭代为基础。组织的安全态势不是静态的，每一秒都在变化，而云技术的兴起加速了这种变化的速度。新的检测和响应覆盖部署后几秒钟，组织的环境就可能会因数百个虚拟机在云端启动，数十个新的 SaaS 应用程序在终端安装等因素而发生变化。因此，安全评估和覆盖范围不能保持静态——它需要随着组织自身的演变而进化。因此，安全是一个过程，而不是一个功能——一个基于持续评估和持续优化组织安全态势的过程。第三，未来的行业必须以 API 优先的方式大规模地处理事务。那些安全团队必须登录数十种工具手动微调某些配置，甚至更不用说手动部署安全解决方案的日子已经一去不复返了。一切都必须通过 API 在机器规模上完成。第四，网络安全将见证商业工具的世界与开源世界共存并紧密集成。虽然软件工程领域长期以来一直如此，所有的商业软件工程工具都在利用开源库和组件，但在网络安全中，开源往往被视为与供应商市场分开的。我之前深入探讨过开源在网络安全中的作用，我认为随着行业的成熟，这一作用将会增长。网络安全供应商不能仅仅通过创建开源工具的商业版本来敷衍了事；他们需要在此基础上增加真正的价值，而不仅仅是声明“我们不是开源的”并展示他们的 SOC2 合规证书。采取工程方法处理安全意味着专注于改进连续交付防御的流程，而不是仅仅满足合规要求。它赋予安全团队在建议招聘更多人员之前交付技术解决方案和构建可扩展工具的能力，从而让他们用更少的资源实现更多的目标。所有这些因素结合在一起，使得我之前深入讨论过的基于证据的安全方法成为必然；问题不再是是否会发生，而是何时发生（答案：已经开始发生）。当我们思考安全问题时，首先浮现在脑海中的一个问题可能是“安全在软件开发生命周期中属于哪个环节？”。虽然这是一个合理的问题，但仅关注软件开发生命周期会导致对软件在实际使用中发生的情况视而不见。为了恰当地讨论工程方法在网络安全中的角色，必须从整体上审视产品生命周期，这不仅包括软件是如何构建的，还包括软件在生产环境中开始使用后会发生什么。历史上，安全与构建产品的开发团队是隔离的，因此，它被视为确保“合规”的最后一步。诚然，安全并不是软件开发生命周期（SDLC）中唯一作为孤岛存在的部分；产品管理（PM）、设计、工程（通常分为前端和后端）以及质量保证（QA）等也是各自为政。在敏捷方法普及前，软件开发大致如下进行：- 后端工程师完成他们的工作部分并将剩余部分发送给前端团队
这种传统的工作流程导致了各个团队之间的沟通障碍，也影响了安全的有效整合。随着敏捷开发的采纳，跨职能团队的理念得以确立，促进了不同团队之间的协作和沟通，进而提高了安全在产品开发全过程中的重要性和效率。由于合适的人没有在合适的步骤中参与，这种传统的所谓瀑布式方法导致了大量的浪费、低效、返工和错误决策。敏捷方法及其 Scrum 和 Kanban 框架带来了短周期迭代和频繁的代码发布，最重要的是，它创建了跨职能的产品团队，其中产品经理（PM）、设计师、软件工程师和质量保证（QA）人员共同工作。实际上，这意味着软件工程师和质量保证人员会在需求和设计被认为是准备好开发之前提供反馈，而产品经理和质量保证人员则在产品构建过程中提供意见，减少了后来废弃代码并重做已“完成”工作的需要。敏捷并没有解决所有问题。特别是当 DevOps 出现时，DevOps 工程师发现自己对产品团队的工作缺乏任何上下文理解，这使得他们的工作变得被动且难以执行。直到最近，安全在成为开发组织的一部分方面仍然落后，作为一个孤立的检查站存在，在最好的情况下，它会在发布时给予批准，并为开发团队分配新的任务，通常标记为“最高优先级”。尽管这仍然是许多组织中常见的模式，但近年来对安全的态度已经开始发生变化。我们看到了 DevSecOps 作为安全对 DevOps 的回应而增长，随着安全被集成到 CI/CD 管道中，其角色正从合规转变为防御的交付。对于新产品开发而言，安全确实开始看起来像软件工程。展望未来，我们可能会继续看到安全团队在其组织内部作为独立单位运营。然而，越来越多的应用程序特定漏洞将由那些构建产品并对代码有最深入了解的软件工程师来处理。安全团队将作为产品开发团队的顾问发挥作用，类似于今天平台和站点可靠性工程师的角色。虽然当谈论软件开发时，很容易想象安全的工程思维会是什么样子，但当涉及到安全基础设施和操作，日常发生、软件开发之后或之外的事情时，要做到这一点则困难得多。这主要是因为应用安全是软件开发生命周期的一部分，而由风险投资支持的云原生初创公司一直在积极寻找保护其代码的方法，并以可扩展的方式进行。相比之下，关于将工程思维、方法和框架引入安全操作、检测与响应、事件处理、数字取证以及其他安全领域，却鲜有讨论。这些公司网络安全流程的关键组成部分通常被视为内部部分，只要在网络中部署了“正确的”产品，并有少数人监控这些产品，就可以很好地完成工作。最重要的是，安全团队经常资源不足，忙于应对最新的紧急情况，以至于无法主动构建防御。毋庸置疑，这种方法已经被证明是有限制性的，而且往往对组织的安全态势有害。虽然我没有证据来支持这一说法，但我推测，大多数（如果不是全部的话）在过去几年中因遭受攻击而出现在新闻中的公司，都已经在其环境中部署了最新和最优秀的工具。这些工具未能保护企业免受安全事件的影响，并不意味着它们做得不好（恰恰相反）。相反，我认为这些事件凸显了这样一个事实：尽管供应商的营销可能暗示产品无懈可击，但实际上没有产品是万无一失的。为了保护我们的企业和人员，我们必须改变我们对待安全的方式。1、认识到工具只是工具，超越供应商选择，关注网络安全作为实践领域的基本原理。这意味着提出诸如“我应该做什么来保护我的组织？我面临的风险是什么？在我的环境中可能发生哪些恶意行为？我是如何检测它们的？当检测到时我将如何响应？”等问题，而不是“我应该买什么工具来保护我的组织？”拥有这一认识后，公司必须将这种做法付诸实践，确保他们对自己的环境有全面的可见性（“单一窗口”），了解他们在检测什么以及如何检测（知道哪些检测在其环境中有效，具体检测什么，以及如何检测），同时具备以可重复方式测试其防御能力的能力。2、 认识到安全操作的许多组成部分可以也应该自动化，并寻找构建可扩展的方式来向组织提供防御。当团队检测到新的漏洞和恶意行为时，他们应该拥有能够以消除明天再次手动应用相同响应来应对同一漏洞的工具。历史上，大多数安全知识都储存在经验丰富的实践者的头脑中，这些人“经历过、做过”。随着行业的成熟，我们需要寻找方法来编码这些知识，使其可共享、可测试，并可供全球各地的组织使用和改进。网络安全始终是一门艺术，因为它涉及与创造性的、智能的对手打交道。然而，如果我们希望继续扩大我们的知识库，并使网络安全防御对那些无法负担“顶尖人才”的组织也变得可及，它也需要成为一门科学。采取基于科学的、工程化的安全方法将使安全团队能够构建系统和流程，以一致的方式开展工作。
文章来源: https://mp.weixin.qq.com/s?__biz=Mzg2MTk4MDM1Mg==&mid=2247484810&idx=1&sn=3e7a3966718d2c70135e2eb830c23f89&chksm=ce0f9625f9781f33915835b302cb78efbef155ad2438bc6f5c567e3921aa1708917561c2ce65&scene=58&subscene=0#rd
如有侵权请联系:admin#unsafe.sh