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