内部资产管理

资产梳理是项非常重要但是目前很难做好的工作 ，无论主动资产发现，还是被动资产发现，或者是通过管理手段，都存在很大不完整性

这里说的透传是针对IP，不管通过多层代理，都会把原始IP一层层传递到服务器端，最终可以捕捉到真实IP

### 0x01 正向管理

资产管理本来应该是正向管理的，试图依靠扫描等技术手段去解决资产管理不足的缺陷，不是正统做法。只能尽可能发现，临时治标，未来会埋下隐患的。

主要有很多历史问题，估计很多企业都很难正向管理的很好。正向管理是一定要有的，就像是代码要有规范和审查，但是需要有逆向思维，来进行检验：

存不存在流程外的机器？

存不存在系统没经过提测和代码审查？

需要扫描发现，然后问责，找到缺失，修正流程，形成闭环

大家都懂的，历史问题，自然操作难度大些，操作也复杂。好比新建项目和整改项目哈，感觉心态放平，逐步推进就可以了。

技术不可什么都能处理好，这不大家都在谈的安全技术和安全管理协同问题嘛哈，多出些技术标准（比如资产登记，更新等）约束执行，再加上技术管控合理配合完成哈。

我们也有流程，每年还会把所有资产拉出来确认一遍，还是感觉心里没底。

IT 人员一般局限于采用技术来解决所有问题，有时能解决些，但效果或体验不一定最优。多考虑技术和流程双剑结合。技术手段发现问题，补全管理短板。

虚拟机，我们在物理机的下面加一页，A 虚机归谁，跑什么业务，B 虚拟归谁，跑什么业务

### 0x02 逆向扫描

![](/media/202201/2022-01-17_152505_565486.png)

技术人员惯性，容易从技术实现和能够达到的效果考虑问题，并且都有一定完美主义的思想在里面，这块应该拉风控或者合规的人聊聊，一起先完善流程，给出我们能提供的手段，也许行政管理部还有一部分职责，他们也面临困扰，那么把职责也分一分，再通过一些监管条文或者案例来洗洗脑，这件事首先个人认为就没法十全十美，如果历史问题积习难改，只能自扫门前雪

结合外部的数据和技术手段来完善资产，可以是一些对外沟通的渠道，比如企业的 src;也可以是一些公网上的资产监测吧

主要是资产发现，另外就是资产指纹识别。通过持续监测每天资产变化也能做到知道业务是否出现变化和异常，假设出现漏洞，也可以通过资产快速圈定影响范围。

核心的问题是对资产这个概念的理解和认识，各个部门不统一，也很难统一，资产管理部门着重于硬件资产、软件资产也就最多是软件授权数，从安全角度的资产、一般也就向运维部门进行理念传输，向资产管理部门传递这样的理念，不用说是某个端口、某个 ip 了，就是某个商业文档纳入资产的概念，对他们老说都是没有任何意义的，说到底，现在这些资产清点理念也不过是安全厂商传递给甲方的概念，主要还是适用于安全部门、运维部门也能借鉴，资产管理制度里面是如何定义对公司有价值的资产的，而且这个制度的话语权一般不会在安全部门

说到资产，每年财务查资产，少了就是事。安全扫描资产，发现没登记的也不见发奖，有些事情叫说了不做，有些事情叫做了不说，安全资产对安全团队就是后者，将安全部门的资产清清点给企业带来的价值向管理层说清楚就有用

资产一方面企业自身需要有健全制度管理。另外也需要持续从外部数据和技术手段不断监测，最终与内部资产管理互补起来。达到出现风险能快速圈定影响资产。

### 0x03 指导方针

世面上还没有成熟产品，误发现太高，同样资产不能关联，都需要二次开发，宿主机与虚拟机的关联

被动发现对于那种不怎么访问的服务有问题。主动扫描漏扫设备一般都有，可能会触发 Bug。

需要在效率，体验，技术，规范之间找个平衡点。

类似安全资产管理这类日常基础工作，平时不酷也不炫，但关键时刻，这种基础工作做扎实了，就能实实在在的围绕资产保障业务的安全，也踏实体现了安全工作的价值。

安全资产管理就比如打地基工作，非常重要也很花时间精力，但这事情不好做，我曾经加上一两年的时间和其他团队沟通敦促维护一个完整详尽准确的资产清单，并设立了具体 KPI，但效果不是很好，其他团队对此不是很上心，觉得没有带来其他价值；和领导去交谈，领导一开始觉得这事情应该很快做好，后来看到各种情况后也慢慢失去了兴趣，现在复盘下，可以需要提高的地方有：

1、不需设立太高目标，要有一定的容忍度，设定 99% 的合规 KPI 耗时耗力还很难达到，不如设定为 90%；

2、需要借助外力，比如财务部门的资产盘点、某项安全事件知道 IP、主机名但不知道谁在使用等情况，让外力来推动。主要涉及 基础架构部门、桌面支持部门，安全部门的定位应该是提要求、看结果，并监督辅助运维部门完成

通常做资产管理不是安全的份内工作，加上“业务优先”所有资产工作历来都不好做。做资产管理类的基础性工作，涉及运维、业务、开发（还有第三方外包开发）多，除了技术以外，管理和流程至关重要（当然，技术手段便利了，有些推动工作也会好一些。）通常都是“先僵化、再固化，后优化”，才能逐步把基础工作建起来。

软资产，谁立项，归谁管，资产管理确实头疼，谁立项（业务）谁负责，负责可以是第三方厂商。有时候数据中心也不会去管这些资产，因为是第三方在维护，虽然资源申请的时候是公司的资源。这部分资产还是属于公司的，但是运维不在运维人员的职责范围内，安全去梳理就需要很大的人物力

谁立项（建设）谁负责 后面还有 谁管理谁 负责 谁运维谁负责，关于资产的认识 得先有制度 而制度中就有范围和解释，安全部门对 资产的要求 跟运维部门 和其他部门不一样，安全部门需要 有Cia三性的估值，运维需要分重要非重要，核心 非核心 等，财务看价值 看年限

发现资产和管理资产，对定义资产的价值是两个维度的事情，安全部门通常只能明确核心业务和非核心也资产，定义不了资产的价值，但需要发现和了解资产才能做好安全。按照大部分单位“业务优先”的原则，安全管理制度，很难让运维、业务、开发、立项（建设）部门，实时的把业务资产的变化提供给安全部门。通常依靠资产发现和管理技术的提升（例如取 CMDB的数据，并且实时跟踪），才是建立安全资产台账的容易实践的路。

资产管理不是安全专业的职责，只是因为资产管理不善影响到网络信息安全啦。这个锅安全部门不应该背

### 0x04 IT 资产

IT资产管理的颗粒度到什么程度比较合适，既能有效管控风险，又不至于过于繁琐没有成就感？

我这边也没能做得多好，痛点运维那边资产管理一般，没有好的自动化统计和发现工具。

IT 资产管理，属于运维职责，可以安全名义推动他们建设。个人浅见，资产安全管理效果如何，主要俩指标:全量和实时，资产必须实时、全量掌控资产动态，基于此才能进一步做好风险评估和管控。有了全量资产，才能根据资产价值和和威胁，脆弱性等数据，做风险评估，得出风险值，施以投入产出比高的措施管控。

资产管理分目标，建议不要一开始就合风险漏洞混在一起，资产是资产，风险是风险，先解决有的问题和准确性问题，如有事能精准定位到人，在逐步解决其他问题。资产管理要依赖很多公司基础设施，资产库、人员离职或异动流程、开发管理等，涉及的方方面面很多

谈到资产管理请问各位都是通过什么平台进行管理呢？CMDB？excel+mysql的居多吧,我们是自建系统，很多资产更新都是通过接口同步，还有流程管控,就算这样，我们的cmdb也有不准的情况,嗯，这个情况肯定会有，这就需要像大佬们分享的要安全运营持续改进，实现每个阶段目标

一般CMDB是什么部门负责运营?IT 资产管理，一般是运维，做资产安全管理也是基于此来做，如前面说的 IT 资产安全管控需要运维和安全协同。

“全量资产难管”背后是历史资产归属梳理问题、还有资产准入（业务上线、变更）制度的落地执行。技术是支撑手段（CMDB、主动探测、流量被动监听、HIDS、辅助 4A 插件检测）。有些可以借鉴的做法是 IT 资产实现“三同步”，其他资产按照业务和数据特征做好分类。再先落实重点资产的梳理，再逐步提高资产识别可管理的百分比，比较容易体现资产管理收益的价值。

其实还有一个重要原因，所有成熟的资产管理系统或者方案，出发点基本都不是安全纬度。所以资产管理系统里的安全属性基本属于不可用状态

资产本身属于运维管辖，资产安全管控属于安全责任和义务，安全在后面督促运维搞事，被动着哈 。太多类似案例，安全往往不能作为牵头人。

IT 资产管理是大运维的基础，同样也包含安全。例如，开发语言，版本，地址转换等，普通运维不太在意，但对安全来说太重要了。CMDB 是全员活动

所以，经常有人说安全和运维是一家，起初安全总是在运维下面，在他们呵护下成长；慢慢长大了，有了更多想法想独立，不然不好成长；继续长大，有了更高视野，想着把运维等什么都掌控在自己下面，安全才好做，你们都听我的

严格按照公司分工，各尽其职，安全才不会被动。在安全维护清单内的资产按照安全管理要求落实的出问题了，安全责无旁贷，不在清单内的资产出问题了，必须追责资产管理部门。避免揽过来，管不了，出问题又扯皮。

关键还是 KPI，运维的没有安全指标，你在人家管的生产服务器上装 HIDS，把人家系统搞摊了，谁干呀,显然呀，你搞安全的跟人家的目标完全不一样

所以扩大参照系，系统被入侵了，影响可用性了运维也跑不了,系统被入侵了，还是得运维上机器处理,得把运维安全 目标绑在一起,利益互绑。。才能推的动

资产的梳理分不同层次，第一个层：数家底，形成资产画像，用于故障时，运维快速定位、处置与恢复；第二层次：进一步用于分析资产的安全性（是否存在风险），尤其在持续安全运营过程中，缺乏不了资产的明晰。所以是相辅相成。

我之前公司运维是有安全考核指标的，因为不打补丁，弱口令等导致服务器和业务系统安全事件，运维是第一责任人

共性问题，领导一听说安全出事，立马叼安全部门，气头上，往往解释苍白无力。

但是很容易只要拿不准的事就扔给安全来决策,潜台词就是出了事就说安全部看过

安全追责顺序如下：谁使用谁负责，谁运维谁负责，谁主管谁负责,安全责任第一责任人是安全与运维共同的老大

有一个前提吧，安全该做的提醒做到位了吧。 连带责任。前提是安全通知到位。如果安全对整个运维没有管控点，只是通知的话，不敢认同连带责任，而且效果也不好。

我们大老板讲究闭环，所以要我们兜底，发现了，为啥不落地，落不了地为啥不上报。领导不同意，为什么再隔级上报,不过说的也有道理，有时候安全执行力的确比较差，博弈太多了。但是只要想一直啃下去 还是可以的。

我们现在计划运维和安全分开，规模小，但也差不多到点了,我们曾经在运维下面，什么都管不了，都不搭理我们 然后全靠各位甲方爸爸的需求，顺利成了直属部门，才能对产品出厂的安全有要求

打补丁这块大家有详细的规章制度要求吗？比如办公终端，生产服务器，开发测试终端，开发测试服务器。

如果有隔离区的话，不上生产问题不大

很多大佬说 CMDB 是人的问题，这里讲的 CMDB 应该是基于 ITIL 的 CMDB，也就是配置项 CI 是事先约定好的，理论上 CI 有变化才是变更，这个我们通过严格的流程（谁不更新 CMDB 领导就考核谁）以及软件版本收敛、定期扫描和自动比对更新，已经控制的还可以了。但是安全想要的 CMDB 跟 ITIL 的不同，我们很难预先知道我们想要哪些，精细化的什么粒度，所以很多时候只能靠 agent 根据需求即时抓，我想 HIDS 也是同样的道理，Tenable 的 agent 也一样。