在与数百家（也可能早过了千家）甲方企业接触后，我们发现企业的信息安全治理水平，直接取决于安全团队人员的技术专业度，而非运营经验值。所谓的技术，并非指渗透和挖洞的能力，而是指软件开发、IT 架构、网络拓扑相关的知识和经验。
站在乙方的角度来看，技术薄弱的安全人员，通常面临着较大的沟通障碍和成本，因为他们难以理解和区分不同安全技术和产品之间的差异。更难以理解自身企业的 IT 和技术现状，无法做出有效且大胆的决策，通常容易被大品牌厂商引导或者选择尽量不作为以此求稳。最终在各方妥协和博弈之下，做出花大钱，成效较差的短期决策。而这些决策，往往在下一任上任之时，予以推翻。
相反，拥有较强技术背景的安全团队，非常明确知道自己想要什么，不会被厂商引导，相对不在意厂商在“付费安全排行榜”中的名次。在企业内部面对业务团队的挑战时，通常也能占有主动权，做出正向的决策，既帮助企业省钱，也帮助企业打下长治久安的基础。
在过去的几年里，威胁检测的透明度受到了高度重视。这个问题吸引了安全从业人员、初创公司的创始人和行业分析师等人的关注。2022 年，两位前 Gartner 分析师 Anton Chuvakin 和 Oliver Rochford 撰写了一篇题为《关于检测中的信任与透明》的迷你论文，文章开头写道：“当我们检测威胁时，我们期望知道自己在检测什么。”这听起来是不是显而易见？但对我们来说，非常明显的是，在整个安全行业历史上，并不总是如此。有些人还记得网络 IDS（入侵检测系统）的早期，这些系统在交付时客户无法看到检测是如何工作的吗。最终市场做出了反应，这些供应商都被 Snort 及其后代产品给淘汰了，后者开放了检测规则以供客户审查和修改。每个组织的环境都是独一无二的，随着 SaaS 的增长和几乎每个领域专用工具的出现，这种独特性还在不断增加。组织中的每个部门都有数十种工具用于管理工作（仅想想为市场营销、人力资源、财务、产品和运营团队设计的用于替代电子表格的应用程序的数量）。除此之外，几乎每家达到一定增长水平的公司都会开发自己的内部应用程序，以应对其运营、商业模式或市场策略中特有的用例。每个组织环境的独特性意味着，攻击者进入每个组织的方式以及防御者在该环境中检测恶意行为的方式都会有所不同。实际上，为了检测特定于其组织环境的威胁，安全团队需要为该特定环境创建检测逻辑。承诺为所有人提供全面覆盖的安全厂商是一个很好的基础层（就像杀毒软件一样），但对于那些有重大损失风险的公司来说，这些基础层是不够的。检测工程在过去的 10 年中取得了巨大进展，这一点得到了那些已有十年经验的人的证实。在上述文章中，Datadog 的安全研究总监 Zack Allen 描述了“越多越好”的检测内容创建方法如何演变为一种成熟的认知，即我们需要高质量、全面的检测内容，而不仅仅是“更多的检测”。曾经被视为“从高塔走下来，向世界宣讲他们最新发现，参加 Blackhat 和 DEFCON 会议的“巫师”的检测工程师，现在已成为众多类型的安全工程师之一。“ 如果你没有网络安全专家，你就无法为你的网络安全产品编写检测规则。这一点同样适用于基于端点、云、应用和主机的检测。
这就像有一群数据科学家构建了一个机器学习模型来检测患者的哮喘，但他们忘记请医生来告诉他们肺炎患者会给模型带来误报。
你需要领域专家，这一点在行业中没有改变，也不应该改变。发生变化的是，这些专家需要具备坚实的软件工程原则基础。你无法在现代环境中扩展所有这些检测并部署它们，或者编写单元测试、集成测试和回归测试，除非有大量的人员或大量的自动化。我可以可靠地说，我的老板更愿意听到我可以通过软件来扩展解决问题，而不是通过雇佣更多的人。”
我看到两个迹象表明检测工程已经发展成为一个专门且定义明确的职业：一是诸如 DEATHCon（检测工程和威胁狩猎大会）、Black Hat、BSides 和其他从业者聚会中的演讲和培训活动数量不断增加；二是开始定义组织在实施检测工程时经历的成熟阶段。Kyle Bailey 的《检测工程成熟度矩阵》是目前最好的尝试，用于衡量组织在这一功能上的能力和成熟度。随着越来越多的组织意识到检测逻辑并非“一刀切”，并且安全厂商不太可能兑现“保护每个人”的承诺，我们开始看到专注于构建检测内容的网络安全初创公司。这些公司不仅仅触发警报，还使规则本身的内容可见且可编辑，从而使安全团队能够了解在他们的环境中究竟检测到了什么，具体是如何检测的，以及检测到时将触发哪些脚本或警报。在这个领域中有两个值得注意的初创公司是 SOC Prime 和 SnapAttack，它们都支持编写检测内容的事实标准语言—— Sigma。这些厂商不承诺全面覆盖，而是为公司提供以完全透明、按需付费的方式访问安全覆盖的能力。不仅组织可以从专门从事检测工程的供应商那里购买通用的检测覆盖，现在还可以让他们的安全服务提供商为其环境定制构建警报逻辑。虽然这还不是所有提供商今天都能提供的服务，但我认为这是行业的发展方向，因为安全咨询公司和托管检测与响应公司正在寻求在供应商选择和警报监控之外提供更多价值。不久，检测工程即服务将成为安全服务提供商的标准服务。值得注意的是，客户期望的变化也在改变端点检测与响应（EDR）和扩展检测与响应（XDR）等安全厂商的运营方式。这些厂商过去常常作为“黑箱”运营，为所有客户运行内部构建的通用检测逻辑，而现在也提供了让客户在其基础上编写自定义检测的能力。例如，我在 LimaCharlie 领导产品，以及 Panther 和所谓的开放 XDR（Open XDR）这一全新类别，这些较新的厂商也提供了对组织安全覆盖的全面可见性（不仅是自定义规则，还包括在组织中运行的所有检测）。我以检测工程为例；我们在安全的各个领域都看到了向工程化转变的强烈趋势。随着基础设施即代码（Infrastructure-as-Code, IaC）的普及，基础设施管理现在由工程团队负责，而非 IT 团队。因此，软件工程技能正逐渐成为安全领域的必备条件。随着云计算的兴起，软件工程的原则和实践现在支撑着基础设施的配置、安全策略和配置的实施、公司安全态势的测试和审查、安全配置变更的实施和跟踪等方面。虽然 DevOps 工程师负责基础设施的配置和管理，但结合了深厚工程知识和深刻安全理解的安全工程师，是最适合保护这些基础设施的人选。当今大多数网络安全专业人士是在 IT 领域发展其技能的，例如设计网络架构、配置防火墙和管理防火墙策略等，这些任务对于维持企业 IT 的正常运行至关重要。不幸的是，许多负责安全的人士对软件工程只有最基本的理解，这阻碍了他们在一切皆代码（Infrastructure, Policies, Detections, etc.）的世界中发展所需技能。当底层基础设施以代码形式存在时，安全专业人士自然需要学会编程。同样的道理也适用于自动化和 API 的使用：由于绝大多数技术任务现在都是通过 API 大规模完成的（包括以前安全团队内部手动完成的工作），我们需要那些懂得如何以安全方式设计、使用和退役 API 的人才。总之，随着技术的发展，安全领域越来越需要具备软件工程技能的专业人士，以应对日益复杂的威胁和管理需求。安全工程团队不仅需要超越运营控制，还要构建解决安全问题的工程方案。随着越来越多的组织意识到现成的安全工具无法满足其独特的需求和环境，那些拥有足够资源和支持以认真加强安全态势的组织，开始不再局限于配置商业产品。虽然在某些用例中，从安全供应商购买的工具可以直接使用，但大多数情况下，这些工具需要一些调整以适应组织的独特需求。然而，我们看到一个日益增长的认识，尤其是在处理大量数据的大型企业和云原生公司中，商业工具无法满足多种安全需求和要求。这些公司开始自行构建其安全堆栈的某些元素，将这些解决方案的设计和开发委托给内部的安全架构师和安全工程师。Appdome 的 Tom Tovar 在他的最近播客中建议，可以将安全组织分为三类：1. 传统安全团队：由技术实力强、对安全和合规有深刻理解和最佳实践的专业人士组成。
2. 先进安全团队：通常包括安全研究人员和安全架构师，负责系统设计、产品评估、渗透测试等任务。
3. 网络安全和工程组织：拥有“硬核”工程人才，能够为现代组织构建和交付安全解决方案。
这些分类反映了安全工程领域的发展趋势，即从传统的安全运营向更高级的工程化解决方案转变。我看到这些类别不是不同的成熟阶段，而是组织需求的演变。云原生公司开始组建与 DevOps、软件工程和产品开发紧密合作的安全工程团队。这样一来，许多传统上由 IT 和安全团队负责的元素，现在由 DevOps 和安全工程团队负责。这种依赖于构建者—— 能够打造安全解决方案的工程人才 —— 的模式并不是每个组织都需要的。然而，随着越来越多的公司从一开始就以云优先的方式启动，随着 SaaS 工具的普及使环境变得更加独特，以及随着更多安全团队认识到量身定制的安全的价值，我们将看到向安全工程的巨大转变。截至撰写本文时，我们看到组织设计的最佳实践尚未跟上安全工程的崛起。具体来说，这意味着虽然安全工程团队有自己的工具需要管理，但在安全工程师、软件/DevOps 工程师以及运营安全团队之间似乎存在许多所有权冲突。可以说，目前在有幸拥有安全工程团队的每个组织中，这些团队的形态都有所不同。组织冲突和不明确的所有权领域是任何新学科形成过程中的自然步骤，因此我们看到的现象是有机且预期之内的。安全运营传统上分为三级，他们在安全运营中心（SOC）团队中扮演重要角色。随着近期自动化技术的进步，这一角色的形态已经开始发生变化：- 一级（Triage Specialist，初步分类专家）
- 二级（Incident Responder，事件响应者）
随着网络安全变得“代码化”，对于那些不会编程的人来说，将会越来越难。首先，随着安全团队寻求提高效率和生产力的方法，SOC 中越来越多的手动流程和程序正在被自动化。其次，人工智能（AI）的崛起有望消除手动分类数千个警报的需要，这可以说是安全团队面临的一个最大痛点。尽管目前 AI 尚未实现自动化的承诺，但它最终会发生。可能比我们想象的要早，我们将看到 AI 与对手训练自己的模型和防御机制之间的较量。抛开这些未来主义的图景不谈，SOC 分析师需要适应安全领域的变化。由于上述两个因素，SOC 分析师（特别是传统上被称为“一级”的分析师）必须开始学习新的技能。尽管行业内有很多悲观主义者认为分析师的未来黯淡，但我有不同的看法。这个角色不会消失，但其形态和范围将会发生变化。过去，作为一名分析师主要是知道如何使用特定的安全产品。现在，安全开始被视为不仅仅是工具问题，而是方法问题。此外，安全工具正在变得商品化和标准化，使得它们彼此相似：如果一个分析师使用过一种 EDR，那么他们很可能不需要太多时间就能掌握另一种。分析师过去使用的确切产品将不如他们对安全基础知识的理解重要。随着行业的成熟，希望保持相关性的分析师需要变得更加技术化。虽然不是每个人都应该成为工程师，但理解威胁行为者如何看待世界以及攻击是如何进行的将变得越来越重要。我认为，安全领域分析师的未来将类似于软件开发中质量保证（QA）专业人员的未来。绝大多数 QA 职位不再是手动的，而是需要使用自动化工具、语言和框架。薪酬最高的职位是亚马逊和许多其他公司现在称为“测试工程师”——专注于测试产品功能和 API 的软件工程师。手动 QA 仍然存在，但很难找到，这些职位竞争非常激烈，由于合格劳动力的供应远远超过需求，它们的薪酬最低。亚马逊的 Mechanical Turk 极大地改变了游戏规则，进一步降低了 QA 的成本。质量保证并没有消亡，但发生了巨大的变革（值得注意的是，这一变化并不需要先进的 AI 和 ML）。总之，随着安全领域的不断发展，分析师需要适应新的技术和方法，提升自己的技术能力，以保持在行业中的竞争力。
原文链接：
https://ventureinsecurity.net/p/the-rise-of-security-engineering
往期回顾：
[1] 不懂软件开发，做不好网络安全（一）
[2] 企业浏览器 vs. VDI，企业到底怎么选
[3] 退缩型 CSO，让老板更加忽视自家安全团队
[4] 大企业搞安全，重点得是开放场景下的数据安全风险
文章来源: https://mp.weixin.qq.com/s?__biz=Mzg2MTk4MDM1Mg==&mid=2247484817&idx=1&sn=56ba38eb9deef3b80196df247c7c6d41&chksm=ce0f963ef9781f28ae42035562144c22b23ef7309c123c5d28550db844e0d0c6b14877d051b1&scene=58&subscene=0#rd
如有侵权请联系:admin#unsafe.sh