如何从收集风险数据到实际降低风险?

简介: 如何从收集风险数据到实际降低风险?

本文来自 企业网D1net公众号

试图保护不断扩大的攻击面的企业最终会发现自己处于十字路口:他们需要超越发现风险,有效地降低风险。

从使用“发现的风险”作为关键绩效指标,转向使用“补救的风险”作为衡量成功的真正标准,这一变化改变了安全团队的激励机制,促使他们专注于风险补救。为了在规模上实现这一点,企业必须在降低风险方面摆脱“救火”模式——这意味着他们必须停止追逐最新的关键问题--并变得更加积极主动。


以下是你可以采取的七个步骤,将你现有的漏洞和风险管理流程和工作流程从消防转变为主动管理大规模风险降低。



步骤1:收集-创建一个积压工作来管理所有积压工作


对你的安全测试工具采用基于调查结果的方法意味着你的典型补救过程从登录到每个工具的仪表板开始。当然,这需要学习每个工具的不同功能,并理解每个工具的调查结果语言。


要过渡到基于修复的方法,请从创建单个待办事项开始。第一步是将来自所有测试工具的所有结果收集到一个集中位置,无论是电子表格、数据库还是其他系统。



第2步:整合-标准化、重复数据消除和利用上下文进行丰富


现在你有了单一的积压,向前迈进一步,将所有调查结果标准化,以便它们使用统一的术语,从而使你能够统一地执行你的补救流程。毕竟,如果你想衡量结果,你需要对所有发现执行相同的过程。这一标准化的积压调查结果现在是所有后续活动的支柱。


你将看到你现在标准化的列表有重复的发现。删除多余的内容以缩短积压工作的长度。


标准化列表还使你能够识别影响同一资源的不同调查结果。在这一点上,你应该用所有权背景来丰富调查结果,这是你未来需要的。例如,从配置管理数据库(CMDB)收集元数据,以在以后分析谁拥有易受攻击的计算机。



第3步:选择-决定执行什么、谁、如何以及在哪里执行补救行动


所有调查结果标准化后,你现在可以选择如何通过多维优先排序方法进行补救,其中包括:


A.内容:选择是要根据外部上下文(例如,已知的自然漏洞利用)还是根据内部上下文(例如,它所在的域-云、代码等)来确定发现的优先级。


B.谁:选择补救项目的发送对象。要确定合适的团队,请分析你在步骤2中收集的资源元数据。


C.如何:通过围绕补救行动进行汇总,确定结果而不是问题的优先顺序。这意味着,如果你对不同的资源或不同的问题有相同的解决方案,则只会生成一个补救项目。


D.在哪里:选择在哪个项目下为补救团队打开工单(例如,在Jira、ServiceNow或修复者使用的任何其他工单系统中)。



步骤4:路线-将补救项目送到补救团队手中


既然你知道谁将执行修复以及要发送它们的补救操作列表,你就可以开始发送它们了。


在这个阶段,你将意识到你能够并行地进行补救,而不是像今天通常所做的那样以顺序的方式进行。


作为一个简单的示例场景,假设你有两个补救团队,Engineering和DevOps,并且你有150个关键发现。接下来,让我们假设前100个调查结果都由Engineering修复,其余50个由DevOps修复。按顺序完成列表将意味着工程团队的修复程序超负荷,而DevOps团队则未得到充分利用。但是,一旦你基于补救操作处理列表,并且你知道将进行补救工作的团队,你就可以并行地补救部分积压。



步骤5:面向接收的解决方案,而不是依赖于安全


这是使你能够真正扩展的步骤:通过创建程序化工作流来自动化积压管理。实现这一点的关键是与其他企业流程同步,并在补救团队需要安全数据时使其可用,而不是在发现发现时提供。


首先,在补救项目和每个不同的补救团队使用的票务系统之间应该有一个工作流程。这样,当发现问题时,票证将自动打开并定向到正确的团队,如步骤3中所定义。你甚至可以更进一步,为每个票务系统创建统一的模板。


你的自动化工作流程应该是双向的,以便在票务系统中关闭票证时,你可以使用下一次测试扫描的结果进行验证。如果发现任何差异,请通过在补救团队的工作流工具中重新打开带有相关详细信息的票据来突出显示它。



步骤6:补救-完成艰苦工作的地方


这是为补救安全问题而进行的实际修复、缓解或风险接受。这是补救过程中的关键部分,但作为安全团队,它不在你的直接控制范围之内。



第7步:报告-衡量实际绩效、效率和风险降低


拥有将补救操作发送给正确的补救团队的自动路由流程,使你可以立即查看整个积压及其状态,而不仅仅是它是否得到了补救。这使你能够跟踪和衡量你的风险降低过程。


有了这些数据,你可以衡量绩效,还可以比较企业内不同团队或组之间的补救绩效。例如,你可以分析和比较不同的应用程序在关键发现、总发现以及团队如何处理他们的罚单方面。


你现在还可以向利益相关者提供有关企业补救计划的报告,使每个人都能够了解该计划的节奏和性能,以及统计数据,如新发现与已解决发现的比率、补救的平均时间和总体积压状态。


这种跟踪使你能够识别补救流程本身中的任何问题,并为安全团队提供数据,他们可以使用这些数据与相应的补救团队更紧密地协作,以增强其流程并解决任何需要改进的领域。


正是这种从产出转移到结果的方法,应该在消除安全成为补救过程中的瓶颈并使过程能够扩展方面发挥带头作用。



相关文章
|
XML Java Maven
jar包导入到项目中、本地maven仓库、私库
jar包导入到项目中、本地maven仓库、私库
3349 0
jar包导入到项目中、本地maven仓库、私库
|
9月前
|
机器学习/深度学习 人工智能 自然语言处理
云上一键部署通义千问 QwQ-32B 模型,阿里云 PAI 最佳实践
3月6日阿里云发布并开源了全新推理模型通义千问 QwQ-32B,在一系列权威基准测试中,千问QwQ-32B模型表现异常出色,几乎完全超越了OpenAI-o1-mini,性能比肩Deepseek-R1,且部署成本大幅降低。并集成了与智能体 Agent 相关的能力,够在使用工具的同时进行批判性思考,并根据环境反馈调整推理过程。阿里云人工智能平台 PAI-Model Gallery 现已经支持一键部署 QwQ-32B,本实践带您部署体验专属 QwQ-32B模型服务。
|
人工智能 Cloud Native 关系型数据库
|
文字识别 算法 Java
文本,保存图片09,一个可以用id作为图片名字的pom插件,利用雪花算法生成唯一的id
文本,保存图片09,一个可以用id作为图片名字的pom插件,利用雪花算法生成唯一的id
|
弹性计算 缓存 监控
基于“日志审计应用”的 DNS 日志洞察实践
DNS 解析日志是一种记录 DNS 请求和响应的基础信息,监控 DNS 服务可以帮助用户识别网络活动并保持系统安全。日志审计服务支持采集 DNS 内网解析日志、公网权威解析日志、GTM 日志。理解 DNS 日志的字段含义,洞察 DNS 日志背后所代表的网络信息,既可以帮助发现和诊断 DNS 解析相关的问题,还可以检测和识别潜在的安全威胁。
8879 110
|
前端开发 数据可视化 API
Python实现智能家居设备的统一控制平台
【10月更文挑战第6天】 Python实现智能家居设备的统一控制平台
747 11
|
安全 网络安全 数据处理
防火墙设置难倒你?这两种组网模式轻松解决网络安全难题!
【8月更文挑战第23天】在网络安全日益重要的今天,防火墙作为关键防护设备扮演着重要角色。本文重点分析两种核心组网模式:三层路由网关模式与二层透明网桥模式。前者通过IP层处理实现内外网隔离及丰富的策略配置,增强安全性;后者以MAC地址转发,部署简便,不影响现有网络结构,适合服务不可中断的情况。通过企业升级安全防护的实际案例,展示了不同模式的应用场景及优势,并提供了三层路由网关模式的配置示例。正确选择和配置防火墙组网模式对于提高网络安全性和保证业务连续性至关重要。
754 0
|
SQL 分布式计算 资源调度
一文解析 ODPS SQL 任务优化方法原理
本文重点尝试从ODPS SQL的逻辑执行计划和Logview中的执行计划出发,分析日常数据研发过程中各种优化方法背后的原理,覆盖了部分调优方法的分析,从知道怎么优化,到为什么这样优化,以及还能怎样优化。
104725 1
|
IDE 程序员 项目管理
程序员都在用哪些神器?
【7月更文挑战第3天】程序员利器:IDE如IntelliJ IDEA、VS Code、Xcode;版本控制Git、SVN;调试用IDE内置工具和Chrome DevTools;数据库管理有Navicat;项目管理Trello、JIRA;协作工具Notion、Typora;API调试用Postman;容器化用Docker;测试用JUnit。这些工具赋能高效开发,提升代码质量。随着技术演进,持续学习新工具至关重要。
166 0
|
供应链 Cloud Native 搜索推荐
商越科技联合阿里云打造数字化综合解决方案,共创智慧采购新生态
企业数字化并非一蹴而就的事情,应用平台的效率、高可用性、安全性等更是为了长远发展而需要提供的保障。
1757 75
商越科技联合阿里云打造数字化综合解决方案,共创智慧采购新生态