我之前曾详细讨论过 。在这篇文章中，我将详述与这种转变相关的趋势之一——即安全工程的兴起。 网络安全的成熟以及从基于承诺的安全转向基于证据的安全 从基于承诺到基于证据的安全和 IT 的发展 当我谈到 的成熟时，我主要是指改变我们处理它的方式。直到最近，我们才将其视为一项功能，并假设安全性是一个工具问题：如果您从顶级供应商处购买“正确”的“下一代”安全产品，您就会“安全”。 网络安全 现在，在看到这种方法如何未能实现其承诺多年之后，我们开始理解安全是一个过程，而不是一个特性。我们正在形成一种系统性的信念，即我们需要回归基础：将安全数据收集到一个地方，了解我们环境中正在发生的事情，了解什么构成了我们组织中的正常业务实践以及什么可能是妥协的迹象，确定如何检测恶意行为并做出适当响应。成熟的安全团队不再使用启用时会激活坚不可摧的防护罩的小部件，而是通过层级和要完成的工作的镜头来看待安全性。 “构建安全态势的最佳方法是将其构建在可以观察、测试和增强的控制和基础设施之上。它不是建立在必须按表面价值接受的供应商承诺之上的。这意味着应该知道您受到保护的确切恶意活动和行为集，并且您应该能够测试和证明这一点。这也意味着，如果您可以描述您想要检测和预防的东西，您应该能够在没有供应商干预的情况下单方面应用它。例如，如果一名安全工程师了解了 WannaCry，他们应该能够创建自己的检测逻辑，而无需等待一两天，直到他们的供应商发布新版本。” 改变安全实现方式的另一个因素是我们在过去十年中目睹的 IT 发展。曾经有一段时间，IT 背景足以成为一名安全专业人员，因为它可以让您基本了解基础设施的不同元素如何工作、如何相互交互，以及需要什么来保护它们。 IT 的自动化和云的兴起正在抽象化背景中发生的许多事情，这使得围绕 IT 基础架构开发心智模型并了解如何保护它变得更加困难。如今，要在安全方面取得成功，需要了解本地基础设施、云基础设施的各种组件，以及基础设施即代码和 DevOps 管道等。随着 IT 变得越来越复杂，对负责维护、管理和理解这种复杂性的人员的要求也在增加。 加速改变我们的安全方式的其他因素包括： - 结果与安全支出之间的相关性较弱， - 业务要求可衡量的结果， - 安全和客户环境的复杂性不断增加， - 安全工具激增， - 安全专业人员日益成熟， - 保险费上涨， - 新一代服务提供商的出现， - 支持供应商生态系统的出现， - 建立安全框架，以及 - 投资者对循证证券的支持。 未来的网络安全看起来很像软件工程 将软件工程视为网络安全的模型 网络安全起源于黑客圈子——在那些对逆向工程产品和工具、修补和破解被认为牢不可破的东西感到好奇的技术爱好者中。然后，几家安全供应商进来承诺安全，说“当发生不好的事情时，我们会提醒你，只要有人检查警报”。对如此简单的前景感到惊讶，我们开始聘请 分析师来监控警报。今天，大约十年后，我们看到我们必须回到基础。显然，这种看法过于简单化了，但事实是我们需要让黑客重新进入这个行业。事实上，未来的网络安全看起来很像软件工程。 安全 软件开发为我们提供了一个很好的模型：业务分析师和产品经理在业务和技术之间运作——他们与客户交谈，理解和评估业务需求，将它们转化为技术需求，并优先考虑这些需求以进行开发。我经常听到安全团队如何因没有与客户交谈并且不够了解业务而受到指责。虽然观点是公平的，但我认为发表这些言论的人没有抓住要点：批评技术安全专业人员不了解业务类似于批评后端工程师不擅长进行用户访谈。道理很简单：如果后端工程师想做用户访谈，他们就不会选择后端，而是成为 UX 设计师。 我们确实需要安全团队来更好地了解业务，这一点毫无疑问。但是，我们不能通过派遣 IT 和安全部门的每个人开始采访整个公司的员工来解决问题（尽管我们应该鼓励建立关系）。相反，我们需要 。 安全领域的业务分析师和产品经理来弥合差距 网络安全的软件工程原则 软件工程提供了一套很棒的工具、概念、原则和心智模型，它们正在共享未来的网络安全。 首先，明天的安全将是安全即代码。 现在我们将一切都作为代码——策略作为代码、基础设施作为代码、隐私作为代码、检测作为代码等等——我们能够部署、跟踪和测试对组织的安全状况，并根据需要回滚它们。反过来，这意味着一种可以测试和验证的方法，进一步巩固了基于证据的安全性。类似于它在软件工程中的工作方式，您现在能够运行自动化安全测试以查看您的系统将如何运行，并聘请质量保证人员（想想渗透测试人员）超越自动机并寻找自动化未涵盖的边缘案例. 第二，未来的网络安全将建立在持续监控、持续部署和频繁迭代的基础上。一个组织的安全态势不是一成不变的，它每时每刻都在变化，而且变化的速度随着云的兴起而加快。在部署新的检测和响应范围几秒钟后，组织的环境就会发生变化，数百个虚拟机在云中启动，并且在端点上安装了数十个新的 SaaS 应用程序，仅举几例。安全评估和覆盖范围不能保持不变——它需要随着组织本身的发展而发展。因此，安全是一个过程，而不是一个特性——一个基于对组织安全状况的持续评估和持续改进的过程。 第三，未来的行业必须以 API 优先的方式大规模地做事。安全团队不得不登录数十个工具来手动微调某些配置的日子已经一去不复返了，甚至需要手动部署安全解决方案。一切都必须通过 API 在机器规模上完成。 第四，网络安全将见证商业工具世界与开源世界共存并紧密结合。虽然软件工程的情况已经有一段时间了，所有商业软件工程工具都利用开源库和组件，但在网络安全领域，开源通常与供应商市场分开。我之前曾深入研究过开源在网络安全中的作用，我看到这个角色随着行业的成熟而增长。网络安全供应商将无法通过简单地创建开源工具的商业版本来逃脱；除了声明“我们不是开源”和展示他们的 SOC 2 合规证书之外，他们还需要在此基础上增加真正的价值。 采用工程安全方法意味着专注于改进持续交付防御的流程，而不是检查合规性框。它使安全团队能够在建议雇用更多人之前提供技术解决方案并构建可扩展的工具，从而使他们能够事半功倍。所有这些因素结合在一起，使得我在之前深入讨论过的基于证据的安全方法成为必然；这不再是是否的问题，而是何时的问题（答案：它已经在发生）。 安全在产品生命周期中的位置 当我们考虑安全性时，首先想到的一个问题是“它属于软件开发生命周期的哪个阶段？”。虽然这是一个有效的问题，但仅着眼于软件开发生命周期就会围绕软件在野外发生的事情创造亮点。为了正确讨论工程方法在网络安全中的作用，必须从整体上审视产品生命周期，其中包括软件的构建方式以及软件开始用于生产后发生的情况。 从历史上看，安全与构建产品的开发团队是隔离开来的，因此，它被视为发布前确保“合规性”的最后一步。诚然，安全性并不是作为孤岛存在的软件开发生命周期 (SDLC) 的唯一部分。产品管理 (PM)、设计、工程（通常分为前端和后端）和质量保证 (QA) 等等也是如此。 在采用建立跨职能团队思想的敏捷之前，软件开发大致如下所示： 产品经理会编写需求并将其发送给设计师 设计师会构建模型并将它们发送给开发团队 后端工程师完成自己的部分工作，剩下的交给前端团队 然后将成品发送到 QA 进行审查 由于正确的人没有参与正确的步骤，这种传统的所谓瀑布方法导致了大量浪费、低效率、返工和糟糕的决策。敏捷及其 Scrum 和 框架导致了较短的迭代和频繁的代码发布，最重要的是它创建了跨职能的产品团队，其中 PM、设计师、软件工程师和 QA 可以一起工作。实际上，这意味着软件工程师和 QA 将在需求和设计被认为准备好进行开发之前提供有关需求和设计的反馈，而 PM/QA 将在产品构建时提供他们的输入，从而减少以后丢弃代码的需要并重新做已经“完成”的事情。 看板 敏捷并没有解决所有问题。特别是，当 DevOps 出现时，DevOps 工程师会发现自己对产品团队正在做的事情一无所知，这使得他们的工作变得被动且难以完成。最终，组织设计的最佳实践迎头赶上，最近，在 2019 年，Manuel Pais 和 Matthew Skelton 发布了我认为最有影响力的技术团队设计指南 - 。在他们的书中，Manuel 和 Matthew 回顾了组织设计的常见挑战，分享了成功的团队模式和互动的最佳实践，并为科技公司推荐了优化价值流的方法。 团队拓扑：组织业务和技术团队以实现快速流动 直到最近，安全才成为开发组织的一部分，作为一个孤立的检查站存在，在最好的情况下，它会批准发布并向开发团队分配新票证，通常标记为“最高优先级” ”。虽然这在许多组织中仍然是一种模式，但近年来安全方法已经开始发生变化。我们将 DevSecOps 的增长视为安全对 DevOps 的响应，并且随着安全性被构建到 CI/CD 管道中，其角色正在从合规性转变为防御交付。由于涉及新产品开发，安全确实开始看起来像软件工程。 展望未来，我们可能会继续看到安全团队在其组织内作为独立单位运作。然而，越来越多的特定于应用程序的漏洞将由那些构建产品并拥有最多代码上下文的软件工程师来处理。安全团队将充当产品开发团队的顾问，类似于平台和站点可靠性工程师今天扮演的角色。 安全基础设施和运营的工程思维 当我们谈论软件开发时，通常很容易想象安全的工程思维是什么样子，但在查看安全基础设施和操作时可能更难做到 - 每天发生的事情，之后，在软件开发之外。这主要是因为应用程序安全是软件开发生命周期的一部分，而由风险投资资助的云原生初创公司一直在积极寻找方法来保护他们的代码，并以一种可扩展的方式来实现。 相比之下，很少有人讨论将工程思维、方法和框架引入安全操作、检测和响应、事件处理、数字取证和其他安全领域。公司网络安全流程的这些重要组成部分被视为可以很好地完成工作的内部部件，只要他们在网络上部署了“正确的产品”并且有几个人来监控这些产品。最重要的是，安全团队一直资源不足，并被最新的火灾消耗殆尽，使他们无法专注于主动构建防御。 毋庸置疑，这种方法已被证明是有限的，而且通常对组织的安全状况有害。虽然我没有证据支持这一说法，但我推测在过去几年中出现在新闻中的大多数（如果不是全部）公司遭受了数据泄露，确实在他们的系统中部署了最新最好的工具环境。事实上，这些工具未能保护企业免受安全事件的影响，这绝不意味着它们做得不好（恰恰相反）。相反，我认为这些事件突出表明，尽管供应商的营销可能暗示什么，但没有任何产品是防弹的，为了保护我们的企业和我们的员工，我们必须改变我们处理安全问题的方式。 将工程思维融入安全意味着几件事，包括： 接受工具只是工具，并超越供应商选择，将网络安全的基础知识作为一个实践领域。这意味着提出诸如“我应该如何保护我的组织？我面临的风险是什么？我的环境中会发生哪些恶意行为？我如何检测它们？当它们被发现时我将如何应对？”，而不是“我应该购买什么工具来保护我的组织？” 认识到这一点后，公司必须将这种方法付诸实践，确保他们能够全面了解他们的环境（“单一管理平台”），了解他们正在检测什么以及他们是如何做的（了解哪些检测在他们的环境中起作用） ，他们究竟检测到什么，以及他们如何检测），以及以可重现的方式测试他们的防御能力的能力。 意识到安全操作的许多组件可以而且应该自动化，并寻找方法来构建可扩展的方式来为组织提供防御。在实践中，这意味着采用检测即代码、基础设施即代码以及已证明在其他技术领域行之有效和可扩展的其他方法。当一个团队检测到新的漏洞和恶意行为时，他们应该拥有相应的工具来响应它们，这样就无需在明天手动对同一漏洞应用相同的响应。 从历史上看，大部分安全知识都掌握在经验丰富的从业者的头脑中，他们“去过那里，做过那件事”。随着行业的成熟，我们需要寻找方法来整理这些知识，并使其可共享、可测试、可访问以供全球组织使用和改进。网络安全永远是一门艺术，因为它要应对富有创造力、聪明的对手。然而，如果我们想继续扩大我们的知识库，并让那些无力聘请该领域“精英中的精英”的组织能够使用网络防御，它也需要成为一门科学。采用基于科学的工程安全方法将使安全团队能够构建系统和流程以始终如一地开展工作。 安全工程的兴起及其如何改变未来的网络安全 检测工程的演变和检测工程即服务的出现 在过去几年中，人们非常重视威胁检测的透明度。这个问题引起了安全从业者、初创公司创始人和行业分析师等的注意。 2022 年，两位前 Gartner 分析师安东楚瓦金 (Anton Chuvakin) 和奥利弗罗奇福德 (Oliver Rochford) 撰写了一篇题为“关于检测中的信任和透明度”的迷你论文，其开篇如下：“当我们检测到威胁时，我们希望知道我们检测到的是什么。听起来很明显，对吧？但我们非常清楚，纵观整个安全行业的历史，情况并非总是如此。我们中的一些人还记得 入侵检测系统是在客户无法看到检测工作原理的情况下交付的。市场说话了，这些供应商都死了，被 及其后代埋葬了，他们开放了他们的检测签名供审查和修改。”对于任何对此主题感兴趣的人来说，这篇博文都是一本很好的读物。 早期的网络 IDS Snort 每个组织的环境都是独一无二的，随着 SaaS 的发展和几乎所有事物的专用工具的出现，这种独特性只会增加。组织中的每个部门都有数十种用于管理其工作的工具（仅想象一下旨在取代电子表格用于营销、人力资源、财务、产品和运营团队的应用程序的数量）。最重要的是，几乎每家达到一定增长水平的公司都会开发自己的内部应用程序，以保存其运营、业务模型或上市战略所特有的用例。 每个组织环境的独特性意味着攻击者进入每个组织的方式和防御者能够检测该环境中恶意行为的方式都是不同的。实际上，对于安全团队来说，要解决检测组织环境特有问题的问题，他们需要为该特定环境创建检测逻辑。 承诺全面覆盖任何人和每个人的安全供应商是一个很好的基础层（防病毒软件也是如此），但对于损失惨重的公司来说，它们还不够。 检测工程在过去 10 年里有了很大的发展，从事 。在上面引用的文章中，Datadog 安全研究主管 Zack Allen 描述了创建检测内容的“越多越好”方法如何演变成一种成熟的认识，即我们需要高质量、全面的检测内容，而不仅仅是“更多检测” ”。 过去被视为“奇才”的检测工程师“从他们的尖顶下来，向世界宣讲他们的最新发现，出席 Blackhat 和 DEFCON”，现在是众多类型的安全工程师之一。 这方面工作十年的人自己都证明了这一点 谈到检测工程，Zack 总结道： “如果没有网络安全专家，就无法为网络安全产品编写检测程序。这对于端点、云、应用程序和基于主机的检测是相同的。这就像让一群数据科学家建立一个机器学习模型来检测患者的哮喘。然而，他们忘记请来一位医生来向他们展示肺炎患者如何给模型带来误报。您需要主题专家。这在业界没有改变，也不应该改变。发生变化的是，这些专家需要扎实的软件工程原理基础。您无法扩展所有这些检测并在现代环境中部署它们、管理冲刺（是的，这就是软件工程 :)），或者在没有大量实体或大量自动化的情况下编写单元、集成和回归测试。我可以可靠地说，我的老板宁愿听到我可以通过软件来解决问题，也不愿听到我雇佣更多的人。” 我看到两个迹象表明检测工程已经发展成为一个专门且定义明确的职业：越来越多的活动，例如 （检测工程和威胁狩猎会议）、Black Hat、BSides 的演讲和培训，以及其他从业者聚会，以及定义组织在实施它时经历的成熟阶段的开始。 的 是衡量跨组织职能的能力和成熟度的最佳尝试。 DEATHCon Kyle Bailey 检测工程成熟度矩阵 随着越来越多的组织意识到检测逻辑并非一刀切，并且安全供应商不太可能兑现“确保每个人安全”的承诺，我们开始看到专门从事构建检测的网络安全初创公司内容。这些公司不是简单地触发警报，而是使规则本身的内容可见和可编辑，这使安全团队能够了解在他们的环境中究竟检测到什么，检测到的准确程度，以及当它发生时将触发哪些剧本或警报被检测到。 SOC Prime 和 SnapAttack 是该领域初创公司的两个著名示例，它们都支持用于编写检测内容的实际标准语言 - Sigma。这些供应商没有承诺全面覆盖，而是让公司能够以完全透明、按使用量付费的方式获得安全覆盖。 不仅组织可以从专门从事检测工程的供应商那里购买通用检测范围，而且他们现在还可以让他们的安全服务提供商构建针对他们的环境定制的警报逻辑。虽然这不是今天所有供应商都提供的东西，但我认为这是行业的发展方向，因为安全咨询和托管检测和响应公司正在寻求增加供应商选择和警报监控之外的更多价值。很快，检测工程即服务将成为安全服务提供商的标准。 值得注意的是，客户期望的变化也在改变端点检测和响应 (EDR) 以及扩展检测和响应 (XDR) 等安全供应商的运营方式。他们通常以“黑匣子”开始，在所有客户中运行内部构建的通用检测逻辑，现在他们还为客户提供在其上编写自己的检测的能力。较新的供应商，如我领导产品的 LimaCharlie、Panther 和全新类别的所谓 Open XDR，也提供对组织安全覆盖范围的全面可见性（不仅是自定义规则，还有在组织中运行的所有检测）。 安全工程的重要性日益增加 我以检测工程为例；我们看到在所有安全领域都在大力推动工程化。通过基础设施即代码，基础设施管理现在由工程部门负责，而不是 IT 部门。因此，软件工程技能正成为安全的先决条件。 随着云的兴起，软件工程原则和实践现在支持如何配置基础设施、如何应用安全策略和配置、如何测试和询问公司的安全状况、如何实施和跟踪安全配置的变化等等.虽然 DevOps 工程师负责配置和管理基础设施，但结合了丰富的工程知识和对安全性的深刻理解的安全工程师非常适合保护它。 如今，大多数网络安全专业人员都在 IT 方面培养了自己的技能——设计网络架构、配置防火墙和管理防火墙策略，以及其他对保持企业 IT 运行至关重要的任务。不幸的是，许多负责安全的人对软件工程只有最基本的了解，这阻碍了他们在一个一切——基础设施、政策、检测等——都以代码形式存在的世界中发展他们需要的技能。当底层基础设施在代码中时，安全专业人员需要学习编码是很自然的。自动化和 API 的使用也是如此：由于绝大多数技术任务现在都是通过 API 大规模完成的（包括以前在安全团队内部手动完成的工作），我们需要了解如何设计的人员，以安全的方式使用和停用 API。 安全工程团队应该超越操作控制，构建针对安全问题的工程解决方案。随着越来越多的组织意识到现成的安全工具无法满足其需求和环境的独特性，那些拥有适当水平的资源和支持以认真对待加强其安全状况的组织开始超越配置商业产品。虽然对于某些用例，从安全供应商处购买的工具可能适合按原样实施，但通常需要进行一些调整才能适应组织的独特需求。然而，我们看到越来越多的人，尤其是在处理大量数据的大型企业和云原生公司中，认为商业工具无法满足大量的安全需求和要求。这些公司开始在内部构建其安全堆栈的某些元素，将这些解决方案的设计和开发委托给内部安全架构师和安全工程师。 Appdome 的 Tom Tovar 在他 中建议，我们可以将安全组织分为三类： 最近的播客 传统的安全团队，由技术精湛的安全专家组成，他们对安全性和合规性以及两者的最佳实践有着深入的了解。 高级安全团队通常由安全研究人员和安全架构师负责设计系统、产品评估、渗透测试等。 拥有能够为现代组织构建和交付安全解决方案的“核心”工程人才的网络安全和工程组织 我认为这些类别不是成熟度的不同阶段，而是组织需求方面的演变。云原生公司开始建立安全工程团队，旨在与 DevOps、软件工程和产品开发密切合作。因此，许多传统上由 IT 和安全团队拥有的元素现在由 DevOps 和安全工程团队拥有。并非每个组织都需要这种依赖构建者（能够制定安全解决方案的工程人才）的模型。然而，随着越来越多的公司从第一天开始就以云为先，随着 SaaS 工具的激增，他们的环境变得越来越独特，随着越来越多的安全团队意识到根据他们的需求量身定制的安全价值，我们将看到一个巨大的转向安全工程。 截至撰写本文时，我们发现组织设计的最佳实践还没有赶上安全工程的兴起。实际上，这意味着虽然安全工程团队拥有自己负责管理的工具，但安全工程师和软件/DevOps 工程师以及运营安全团队之间的所有权似乎存在许多冲突。可以说，时至今日，在每一个有幸拥有安全工程团队的组织中，该团队的形态看起来都略有不同。组织冲突和不明确的所有权领域是任何新学科形成的自然步骤，因此我们所看到的是有机的和预期的。 安全分析师角色不断变化的性质 随着网络安全成为代码，对于那些不编码的人来说，它将变得越来越难。我说的是安全分析师不断变化的角色。 安全分析师传统上分为第 1 层（分类专家）、第 2 层（事件响应者）和第 3 层（专家分析师），在安全运营中心 (SOC) 团队中发挥着重要作用。随着自动化的最新进展，这一角色的形态开始发生变化。 首先，随着安全团队正在寻找提高效率和生产力的方法，SOC 中越来越多过去需要手动操作的流程和程序正在实现自动化。其次，人工智能 (AI) 的兴起有望消除手动对数千条警报进行分类的需要——这可以说是安全团队正在经历的最大痛点之一。时至今日，人工智能尚未兑现其自动化安全的承诺，但它最终会实现。可能比我们想象的要早，我们一定会看到一场人工智能与对手训练自己的模型和防御的战斗——他们自己的。撇开未来的前景不谈，SOC 分析师将需要适应不断变化的安全形态。 由于上述两个因素，SOC 分析师（尤其是传统上称为“Tier 1”的分析师）必须开始学习新技能。最紧迫的技术技能是编码，正如 所说明的那样，分析师明白这一点。 Tines 于 2022 年委托进行的 SOC 分析师之声调查 业内有足够多的危言耸听者认为分析师的未来是暗淡的，但我有不同的看法。这个角色不会消失，但它的形式和范围将会改变。过去，成为一名分析师主要是了解如何使用特定的安全产品。现在，安全性开始不再被视为一个工具问题，而是一个方法问题。此外，安全工具正在变得商品化和标准化，因此它们的工作方式彼此相似：如果分析师使用过一种 EDR，他们很可能不需要太多时间来学习另一种。分析师过去使用的确切产品将变得不如他们对安全基础知识的理解重要。随着行业的成熟，希望保持相关性的分析师需要变得更加技术化。虽然不是每个人都会而且应该成为一名工程师，但他们越来越了解威胁行为者如何看待世界以及如何进行攻击将变得越来越重要。 我认为安全分析师的未来将类似于软件开发中 QA（质量保证）专业人员的未来。绝大多数 QA 工作不再是手动的，而是需要使用自动化工具、语言和框架。薪酬最高的是亚马逊和许多其他公司现在所说的“测试工程师”——专注于测试产品功能和 API 的软件工程师。人工 QA 仍然存在，但很难找到，角色竞争非常激烈，而且由于合格工人的供应大大超过需求，他们的报酬最低。 Amazon 的 Mechanical Turk 极大地改变了游戏规则，进一步降低了 QA 的成本。质量保证并没有消亡，但它发生了巨大的变化（值得注意的是，它并没有采用先进的人工智能和机器学习来改变它）。 未来的安全堆栈 随着安全团队变得更加技术化，他们开始认识到没有供应商可以承诺“安全”和“安全”作为一项功能。传统上，大多数商业安全工具从安全团队中抽象出基础层，并以警报和报告的形式提供高级视图，总结发生的事情。想要了解安全基础设施的基础层和事件级数据的组织被迫使用开源工具或从头构建工具。 由于 DevSecOps 方法需要对安全基础层的可见性，因此当我们查看所谓的网络安全市场地图时，未来的安全堆栈将与我们今天所看到的截然不同。首先，我们将看到越来越多的中立解决方案，从业者可以使用这些解决方案来询问他们的系统，全面了解他们的环境，并建立适合他们需求的安全覆盖范围。这些工具将透明地工作，它们所做的工作将很容易被测试和验证。重要的是，我们将看到商业和开源解决方案的结合，它们可以协同工作以解决组织的安全用例。安全的中心将是流程和安全专业人员——而不是“产品”，因为工具就是工具；重要的是它们的使用方式和用途。 在过去的几年里，我们开始看到越来越多的安全领导者拒绝盲目信任供应商的想法：这是我们在我领导产品的 LimaCharlie 推广的方法，以及其他新一代解决方案所采用的方法，例如SOC Prime、Panther、Prelude 和 Interpres 等等。 最近的 下图列出了当今采用基于证据的工程安全方法的公司和开源工具。它并不意味着面面俱到（还有更多符合上述标准的优秀工具），它也不是传统的“市场地图”。 缩小人才缺口 要聘请优秀人才，企业需要改变其工作方式 保护企业免受恶意行为者侵害的安全团队压力大、人手不足、价值被低估且薪酬过低。事实上，黑客组织比任何公司都更善于吸引技术人才。他们免税支付给他们，而且比任何企业都要多得多。他们提供了良好的工作与生活平衡、黑客的快感和成就感。他们中的大多数都是 100% 匿名的。无需积累毫无价值的证书并每隔几年支付几百美元来维持它们的“最新”，无需与招聘人员、人力资源、基本合规培训、职场政治、法律、合规、工资单和苛刻的老板打交道最重要的是。如果这听起来像是我在宣传为对手工作——那完全不是我的本意，事实是这些对于经验丰富的安全专家来说都不是新鲜事。我只是想证明，要聘请优秀人才，企业需要做得更好。 这篇文章再加上许多最优秀的安全专业人士没有动力去应对为大公司工作的官僚作风，描绘了当前就业市场的惨淡景象。 暗示我有一份快速简便的解决方案清单是不道德和不真实的，所以我们作为一个行业必须一起找到它们。我们可以首先放弃对入门级工作“5 年经验”的要求，并在此基础上继续推进，消除偏见并改进我们的招聘流程。 让软件工程师做安全 随着安全领域的一切都变成代码，很少讨论的网络安全人才管道之一可能是软件工程。一些人认为，向工程师教授安全知识可能比向技术安全专业人士教授软件工程更容易。虽然我不是对这种说法的正确性做出判断的合适人选，但我已经看到足够多的软件工程师转变为安全从业者，从而知道这条道路是真实的。 挑战在于让人们知道网络安全是软件工程毕业生的一条可行的职业道路，为他们提供正确的培训（在计算机科学课程中添加深层次的网络安全课程），并为他们设计有意义的职业道路以找到自己的出路网络安全。这就提出了一个新毕业生可以获得的许多入门级网络安全工作的薪酬问题：如果一个人能够在软件领域找到第一份工作，其薪酬比他们在安全领域提供的任何工作高 20-40%（如果他们甚至可以获得面试机会） )，让软件工程师来做安全的整个想法都失败了。 培养新一代安全工程师 关于网络安全人才短缺的话题很多，很容易注意到一大群新进入者承诺解决这个问题。从为期 6 周的网络安全训练营到在线课程，以及新的学院和大学学位，每个人都想在“安全教育的未来”中分一杯羹。人们很容易认为我们所需要的只是让更多的高中生和成年人准备好改变对安全感兴趣的职业并参加这些项目，3-5 年后我们都准备好了，我看到问题变得更深了。 如果你看一下绝大多数的教育项目，你会发现他们的课程往往忽略了工程部分。我没有花足够的时间来整理数据，所以我对这个话题的观察相当轶事，但这是我所看到的： 大多数训练营的时间都很短，水平也很高，以至于认为它们可以为毕业生提供该行业的任何深入知识是不合理的。我遇到过许多参加过训练营的优秀安全专家。然而，他们变得伟大并不是因为他们必须参加训练营，而是因为他们在外面所做的事情。我并不是说这些简短的沉浸式课程没有任何价值。为了说明我要表达的观点，我鼓励您思考为什么有那么多 4-8 周的前端开发训练营，而 4-8 周的后端开发培训如此之少。答案很简单，因为后端开发与安全性类似，需要对深入的技术理论和概念有扎实的理解，并且能够处理这些概念并在代码中实现它们，而通常没有任何视觉反馈。我要郑重声明，你无法在教人们如何创建一个简单网站所需的相同时间内教授这些内容。 许多大学课程，尤其是硕士课程，更侧重于制定政策而不是培养实践技能。即使是那些更深入和实用的，也往往是大学教育的整体——太陈旧、太理论化、太浅薄。安全每天都在发展，每天都有新的漏洞利用、新的漏洞、新的攻击向量和新技术一起出现。大学项目要经过漫长的审批、严格的学术审查和评估，以至于一个项目获批时，谈及六个月或更长时间前的新闻。有一些优秀的教师和讲师正在努力跟上行业的步伐，并向学生传授有用、实用和最新的技能。我们都应该对他们的工作深表感谢，但值得一提的是，这些人并没有按照教育系统本身的方式工作，而是绕过其局限性为学生和社会做好事。 网络安全认证并不能反映市场所需的技能和经验。我无意减少人们为它们付出的努力，我也不认为它们没有任何价值。相反，我的意思是，除了极少数例外，这些认证提供了理论概念，让人们觉得他们知道应该如何实现安全，但没有提供任何实际操作的实际技能。当攻击者深入代码并寻找绕过控制、利用漏洞和泄露数据的方法时，我们似乎认真地认为我们可以通过教人们如何编写策略和通过有关云安全的多项选择题考试来阻止他们.想象一下，由一位拥有“心中证书”的心脏外科医生进行手术，他一生中没有做过一次手术（我做不到）。 所有这一切都在说今天最好的安全专家不是来自大学，明天也不会出现。成为安全工程前沿专业人士的人来自渗透测试、军事、国家安全局和其他具有强大攻击性成分的政府机构的实践工作。他们来自认真对待安全的云原生企业中成熟的安全团队。他们在计算机前、CTF（夺旗）比赛以及 Open SOC、Black Hat、DefCon 等活动中自学成才。 为了塑造安全的未来并缩小人才缺口，我们不能坐视有足够积极性的个人找到一种方法来自学他们需要的技能来保护我们的人民、企业和国家。希望不是一种策略，为期 6 周的训练营也不是；我们需要建立系统和机构来缩小技术网络安全差距。安全很难。教授安全性也很困难，但需要完成。合规性和政策制定很重要，但它们本身并不能帮助我们保护我们的网络免受攻击者的攻击 - 非常有才华、技术高超、积极主动且薪水丰厚。 虽然我们需要找到让软件工程师进入网络安全领域的方法，但我们还需要高度专业化的安全专业人员来获得工程技能。虽然并非每个事件响应、数字取证和端点安全从业者都会成为一名工程师，但大多数人都会受益于了解软件开发的基础知识并熟练掌握 Python 等语言。采用工程方法进行安全操作将使我们能够自动化事件响应的手动部分，并不断构建可扩展的方法来保护组织的边界，同时花更多时间主动构建防御。为此，网络安全教育必须开始包括软件工程课程，就像软件工程和计算机科学学位应该教授安全基础知识一样。 结语 确实没有灵丹妙药可以解决我们所有的安全问题，培养更多的安全工程师也不会做到这一点。然而，采用工程安全方法可以帮助我们从一开始就将安全性构建到软件产品中，加速行业的成熟，并使我们的安全操作面向未来。 人才短缺肯定会成为一个障碍。然而，仅仅因为我们没有我们需要的资源，我们不能也不应该放弃解决这个难题的可行方案。同样清楚的是，我们必须改变我们的招聘做法，并重新评估用于确定未来安全领导者的标准。我们得到了我们优化的东西。每天，攻击者都在花费无数时间学习新技术、对我们构建的软件进行逆向工程，并寻找代码中的漏洞。如果我们查看安全职位发布，很容易得出结论，我们希望通过多项选择测试和获得认证来阻止对手，这些技能与了解代码工作原理和防御代码所需的技能截然不同。 我相信网络安全的工程方法是不可避免的。我们已经开始看到它增长的迹象，而且只会从这里加速。问题是——我们能够以多快的速度为它的发展建立基础设施？如果历史教会了我们什么的话，那就是网络安全实践的整体状况比在 DefCon、Black Hat 等会议上发表的最新和最伟大的演讲要落后很多年。我们将不得不看看接下来会发生什么改变行业的事件。 本文的主图是由 HackerNoon 的 通过提示“网络安全”生成的。 AI 图像生成器
