0x00，工作负载漏洞管理需求在中大型政府或企业的安全治理过程中，一个无法回避的问题是承载业务系统的工作负载漏洞管理，无论是在平台建设初期，上级监管部门对平台保护、合规有监管要求；还是在网络防护和再防护期间，或者日常安全操作中，防范犯罪团伙的APT攻击。所有这些都需要对工作负载进行有效的漏洞管理。但是在我接触过的用户中，安全运营团队能够充分利用安全产品，达到预期的效果。用户不多。从工作负载漏洞管理的价值来看，1.提升安全防护性能的工具在CSO眼中，工作负载管理系统是一个提升安全防护性能的工具。通过产品提供的能力，可以减少安保人员的时间投入。当你是一名安全运维人员，负责数千台或数万台服务器的漏洞管理时，你需要的是：1.全网工作量的快速漏洞检测。当你刚到一家公司时，没有商业漏洞管理工具。漏洞信息只能在单机上通过传统的脚本进行统计，然后汇总在一起使用excel输出漏洞报告。此方法至少需要1个工作周。安全运营投资的投资回报率太低。2、批量自动修复检测到漏洞列表后，需要进行修复。如果通过脚本修复，需要将修复失败的原因上传到服务器。同时，在维修过程中出现的各种问题也要及时处理。例如：物理机内核补丁修复、云主机内核漏洞修复失败、容器内置组件。2、工作负载漏洞运营的另一个价值点是提升安全防范能力。1、当最新的漏洞出现时，需要及时修复，防止公网和内网0day入侵。2.网络保护/重保期间，由于业务系统组件迭代频繁，很多新组件引入新漏洞，需要防范公网和内网0day入侵。例如：应用于宿主机本地提权的漏洞，入侵常用fastjson的web组件等。3、如果是政务云系统，需要通过合规等级，需要导出累计修复的漏洞列表。3.目标对象目前公有云、私有云、混合云主要有两部分。一是租户端工作负载的漏洞管理。涉及的对象包括虚拟主机、原生容器&K8s、用户自建容器&K8s。虚拟主机是目前的主流工作负载，一些创新型企业开始尝试容器平台替代虚拟化平台，以进一步提高资源利用率。所以自建容器&k8s需要支持。对于安全性要求比较高的企业，容器平台使用的原生容器（带简化操作系统做隔离），这种场景也需要支持。对于平台端安全来说，其实就是物理机和容器平台。0x01。产品设计整体架构设计业务流程分为漏洞库构建、客户端采集软件信息上传比对、漏洞信息展示修复。1、通过网上各种漏洞数据源，定期下载相关文件，xml分析，将每条漏洞数据按要求写入elasticsearch。2、同时下载yum/apt源数据，并将yum/apt对应的软件版本设置为低于漏洞数据源所期望的软件版本，并设置为不向用户显示。新增漏洞在测试环境自动修复，修复失败的软件也设置为对用户不可见，实现漏洞库的权限管理。3、当前端用户点击全局验证后，服务器端任务管理系统会发出检测命令，客户端会上传rpm和deb包数据。通过比对程序将存在漏洞的软件写入漏洞展示库elasticsearch。4、当前端用户点击自动修复时，通过服务端任务管理系统下发自动修复命令。由客户端执行，结果反馈给elasticsearch。模块一：漏洞库建设@1。需要获取RSHA和USN漏洞相关资源，主要根据开源操作系统提供的漏洞公告，关联对应的CVE数据。然后使用CVE中的CVSS对漏洞进行评级或分类。中文部分调用自然语言学习API处理存储。https://oval.cisecurity.org/repository/downloadhttp://cve.mitre.org/data/downloads/index.html需要提取的字段@2，提供产品调用OpenAPI1，漏洞检测OpenAPI输入：由客户端软件获取名称和软件版本，返回：以上所有字段2.漏洞库管理API需要实现漏洞库的访问机制；同时对库中的各个字段进行编辑，包括：前端显示与否、中文描述、RHSA/USN安全公告中文、安全公告类型标识中文、安全公告类型标识英文@3，提供增量更新机制模块2：客户端数据采集数据库结构设计rpm-qa获取软件包信息yumdeplist通过日志模块上传到logstash，写入elasticsearch服务器。模块三、漏洞展示&修复数据展示部分：从主机和漏洞公告的角度展示相关的漏洞信息。同时通过漏洞安装状态返回，如：依赖版本修复状态、yum/apt源配置。任务下发部分：通过用户界面触发全局验证，或单项验证，或单项漏洞验证。通过任务控制模块传递给客户端，执行日志上传模块。0x02。漏洞运营产品的可用性再好，也需要人员维护。在产品方面，尽量做到标准化，当然也会出现不正常的情况。这时候就需要产品开发团队和用户漏洞运营团队通力合作解决问题。如需转载，请注明原文地址。
