此话题由圈子里的朋友提出，借此发挥一下，把自己的不靠谱经验总结一下，至于痛点如何解决，只说一句：小鸡不尿尿，各有各的道。
第一部分：漏洞预防
活动任务一、漏洞扫描检测
| 序号 | 痛点名称 | 痛点描述 |
| 1 | 漏洞扫描影响性能 | 远程扫描可能影响网络和应用性能，本地扫描可能影响主机瞬时性能。 |
| 2 | 隔离网络扫描执行难 | 隔离网络网络不可达，需要物理接入，人工操作繁琐，费时费力。 |
| 3 | 扫描点权限风险 | 远程扫描若全网可达，扫描虽方便但权限过大可能存在安全风险。 |
| 4 | 扫描检测误报问题 | 远程扫描时通过获取版本匹配判断漏洞存在否，误报较高，屏蔽版本无法识别。 |
| 5 | 漏洞扫描时间长 | 远程网络扫描不能并行检测，漏洞逐一匹配判断，漏洞越多时间越长。 |
活动任务二、安全测试检测
| 序号 | 痛点名称 | 痛点描述 |
| 6 | 漏报问题 | 在存在防护设备如WAF时，测试成本增加，可能产生漏报。 |
| 7 | 检测时间受限 | 部分业务受安全测试时间影响，容易漏报。 |
| 8 | 检测功能受限 | 部分功能不具备安全测试条件，容易漏报，如测试环境。 |
| 9 | 个人经验覆盖率问题 | 专业服务由小团队完成安全测试，发现漏洞无法保证全面覆盖。 |
| 10 | 众测不可控问题 | 众测水平参差不齐，更可能存在恶意行为。 |
| 11 | 漏洞触发影响业务 | 测试中为探测漏洞，可能导致业务瘫痪，如危险命令。 |
| 12 | 脏数据问题 | 测试中可能导致后台数据插入脏数据。 |
第二部分：漏洞收集
活动任务三、获得安全漏洞通告
| 序号 | 痛点名称 | 痛点描述 |
| 13 | 漏洞价值低 | 安全漏洞通告的漏洞价值低，企业无法使用，多数得忽略，浪费人力资源。 |
| 14 | 漏洞通告不专业 | 缺少CVE、受影响版本、不受影响版本、自查手段等必要信息，使用时增加成本。 |
| 15 | 漏洞信息混乱 | 短时间内连续相似漏洞的漏洞信息来源多，各信息编号不统一，容易混乱。 |
活动任务四、获得威胁情报
| 序号 | 痛点名称 | 痛点描述 |
| 16 | 资产不清晰 | 不知道哪些资产受影响，是否有遗漏的资产。 |
| 17 | 多源漏洞情报整合问题 | 多来源漏洞情报格式差异、漏洞信息字段错误，增加使用成本。 |
活动任务五、获得SRC漏洞信息
| 序号 | 痛点名称 | 痛点描述 |
| 18 | 运营难问题 | 白帽子水平参差不齐，漏洞质量难保证，白帽子资源维护难。 |
| 19 | 漏洞审核难/效率低 | 审核靠个人经验，漏洞信息不完整审核效率低。 |
| 20 | 平台功能复杂成本高 | SRC平台与内部工单、OA、CMDB、邮件、短信等对接，功能复杂，开发成本高 |
活动任务六、获得补丁文件/版本程序
| 序号 | 痛点名称 | 痛点描述 |
| 21 | 无有效的补丁可用 | 有情报/漏洞信息，但官方无补丁。如0day。 |
| 22 | 补丁获取难 | 部分漏洞的安全通报和补丁号对应不上，官网找补丁很麻烦。 |
| 23 | 应用补丁开发周期长 | 供应商对部分应用的漏洞开发补丁，时间不可控，开发周期长。 |
| 24 | 老旧低版本补丁不支持 | 供应商产品架构调整，补丁不支持老旧低版本产品，无法获取或获取需收费。 |
第三部分：漏洞消减
活动任务七、漏洞评估
| 序号 | 痛点名称 | 痛点描述 |
| 25 | 漏洞验证难 | 部分漏洞可能没法验证，危害难直接体现，只能依据官方公告。 |
| 26 | 漏洞评定标准问题 | 对发现的漏洞需要综合评定，结合资产、利用难度、影响用户等全靠团队经验。 |
活动任务八、明确修复措施
| 序号 | 痛点名称 | 痛点描述 |
| 27 | 修复措施评审问题 | 采用临时性缓解措施、补丁修复、版本升级等措施全靠团队经验，还会涉及业务团队。 |
| 28 | 漏洞策略审批难 | 哪些漏洞打，哪些漏洞不打全靠经验，无法自动化评估漏洞、补丁级别、自动审批。 |
活动任务九、测试验证
| 序号 | 痛点名称 | 痛点描述 |
| 29 | 补丁有效性测试难 | 测试与生产环境差异，导致漏洞在测试环境补丁修复验证成功，但不等于生产环境也成功。 |
| 30 | 补丁安全性问题 | 漏洞修复成功可能引入新的风险，引入二次、多次漏洞的新问题。 |
| 31 | 补丁兼容性问题 | 对系统的影响测试环境可能无法全面验证。 |
| 32 | 新/高版本不支持问题 | 采用升级版本修复漏洞时，应用系统可能不支持新/高版本。 |
| 33 | 虚拟补丁兼容性及性能问题 | 采用虚拟补丁时，可能更加会受到兼容性和性能的影响，不好评估。 |
活动任务十、制定修复方案
| 序号 | 痛点名称 | 痛点描述 |
| 34 | 补丁修补前备份数据难 | 备份数据往往比漏洞修复过程时间长、执行成本更高。 |
| 35 | 补丁依赖关系难清晰 | 老旧操作系统打补丁，往往需要SP大版本支持和其他补丁依赖关系，不易操作。 |
| 36 | 补丁回退问题 | 各种意外导致的补丁回退问题，方案可能很难考虑全面。 |
活动任务十一、修复实施
| 序号 | 痛点名称 | 痛点描述 |
| 37 | 版本控制不完善 | 由于版本控制管理不完善，导致修复新漏洞时导致版本回退，旧漏洞重现。 |
| 38 | 变更安全性问题 | 由于修复漏洞变更操作不规范，导致修复后配置参数变化，影响业务。 |
| 39 | 自动分发/升级补丁风险 | 采用自动化运维系统对补丁自动分发时，可能出现个别分发异常情况。 |
| 40 | 大规模升级风险 | 大规模升级时，一点补丁产生bug会影响面非常大。 |
| 41 | 补丁修补成本高问题 | 如CPU漏洞，硬件架构导致的漏洞等解决成本过高。 |
| 42 | 隔离网修复操作成本高 | 隔离网络中，补丁或程序重新部署由人工逐一操作，成本很高。 |
活动任务十二、修复复核
| 序号 | 痛点名称 | 痛点描述 |
| 43 | 补丁修复复核难问题 | 部分漏洞修补后版本无变化或小版本变化，远程漏洞扫描时无法识别漏洞是否修复成功。 |
| 44 | 复核时间延迟问题 | 受业务影响，可能修补后无法第一时间进行复核，出现问题不能及时发现。 |
| 45 | 修复后的评估监控难问题 | 漏洞补丁升级后，平稳度、兼容性等量化评估、监控难得问题。如打补丁后一周系统异常。 |
第四部分：其他
活动任务十三、效率
| 序号 | 痛点名称 | 痛点描述 |
| 46 | 跨部门协作效率问题 | 漏洞修复的方案、测试、记录、工单跟踪、执行操作等多部门协作困难及效率不高。 |
活动任务十四、工具
| 序号 | 痛点名称 | 痛点描述 |
| 47 | 缺少易用的补丁工具 | 微软WSUS/SCCM、Dell KACE、Red Hat、IBM、VMware等平台的补丁系统集成各种问题。 |
| 48 | SRC平台问题 | 商用SRC平台和自研SRC平台的各种困扰。 |
| 49 | 漏洞管理可视化的问题 | 漏洞的发现、测试、修复等过程可视化呈现难，不容易体现各团队工作量及工作效率。 |
活动任务十五、责任
| 序号 | 痛点名称 | 痛点描述 |
| 50 | 定责难问题 | 由漏洞修复引发的安全事故，涉及多角色各环节。如检测人、审核人、测试人、升级操作人等。 |
坚信少却更好，坚定元认知传播，坚持安全美学，拿个主题，讲300秒就够了。
原文始发于微信公众号（表图）：甲方企业漏洞管理活动的50个痛点总结
免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉。
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论