正本清源:安服究竟是什么?

  • A+
所属分类:安全闲碎

本文作者:Torjan(信安之路安全建设小组负责人)

知乎 ID:LinuxSelf

最近听到很多关于安服的声音,有好的也有不好的,鉴于我是唯心派,就是那种讲究一切从心的思维,对于一些对于安服存在的偏见的声音有太多的感慨,所以也想表达一些自己的看法,对与不对,自己心中有数即可,也欢迎大家畅所欲言;

文章主要讲述自己长期以来对于安服的见解,以及给一些即将要加入安服的人一些参考,建议谈不上,个人偏见而已;

总体来说,对于安服大多有 2 种:

1、安服不行:尤其是驻场安服,整天无所事事,陪着客户喝茶,职业,个人,技术完全得不到提升

2、安服好啊:门槛低,人肉工具,管你是大佬还是应届,上就是了

以上是常见的 2 种偏见,我是安服出身,不会说好与坏,只是从安服本身去聊聊这些年安服的情况和我眼中的安服应该是怎么养的。

0x00 起源

安服的起源从什么开始,我们不得而知,大多数的安全从业人员对于安服的印象都来自于解决设备不能解决的问题,或者是驻场,扫描,渗透啊,人肉工具,实际上安服真的是这样么?

这里从安全需求方和安全服务方(参考 elknot)来说说安服的大致起源;

1、安全需求方:早在 2015,2016 年开始,安全服务就已经冒头了,期间大多数安全服务方提供大型系统上架前的安全技术和管理评估,协助完成等保 1.0,风险评估等合规要求,解决安全需求方现场安全技术不足,人员缺乏等情况下的安全合规需求;

2、在安全服务方来说:铁盒子解决方案在一定程度下是市场大鱼吃小鱼的结果,如何从其他纬度突破安全服务方之间的壁垒,一个是低价策略,一个是服务水平,而安全服务恰好是安全服务方用于突破铁盒子不能解决的问题下的产物,同时解决安全需求方在安全技术不足,安全人员缺乏下的安全合规要求;

从安服出现,到安服市场开始增长,期间经历了很多事件,最早出现一次是永恒之蓝,奇安信建立应急响应驱动服务的思路,开始对外扩展;将安全服务直接分成技术服务和咨询服务,分工合作;深信服直接从等保,合规去解决安全需求方的安全服务需求,主要的安全服务有等级保护实施、安全技术控制、IT 风险评估、渗透测试、应急响应、IT 治理咨询、IT 审计(稽核)外包等;启明星辰通过在各地建立安全运营中心,推动等级保护,云计算安全,态势感知,移动安全,工业互联网安全;还有天融信等等,这里不做过多描述,我们从这些服务内容大致可以发现几个点:

(1)针对性的提供安全服务:有针对行业的,有针对性特定的安全风险场景,有基于安全面的(数据安全,应用安全...)

(2)云化:不得不说上云是趋势,如何快速的提供服务和适配是各大安全服务方的挑战;

(3)合规:咨询和技术服务一直都是分庭抗礼,相辅相成

0x01 偏见

这里主要针对安服不行,安服很好这两种思维聊聊自己的想法;

安服不行论

从安服的出现来讲,存在即合理,如果说安服不应该出现,那么在很早的阶段,安服就会被铁盒子所替代,根本不需要所谓的安服,这是一方面;另外就是安服究竟是什么?

安服:安全服务,安全服务是由供应商、组织机构和人员所执行的一个安全过程和任务,安全服务也指适应整个安全管理的需要,为企业、政府提供全面或部分信息安全解决方案的服务。安全服务是安全控制的综合,可以划分为关注于程序与风险的管理的安全管理类服务、关注于由人员来实施并实现安全控制措施的安全运行类服务和关注于具体安全控制措施的安全技术类服务。(选自一个网络安全老兵眼中的网络信息安全服务企业)

用最最简单的一句话来说就是安服是用来解决问题的;安全服务是通过一系列技术,管理等风险控制手段去解决现有安全问题,满足安全需求方需求的方式;所以安服可以是甲方也可以是乙方,可以对内服务,也可以对外服务;

安服不行的原因是因为没有解决问题还是因为问题太简单?既然有明确的原因,那么我们可以更进一步。

安服没有解决问题,我在客户那被怼的亲妈都不认识了,那么到底是什么原因导致问题没有解决?是资源不到位?还是安全需求方需求没把握住?从根源入手去解决问题。

安服问题太简单了,就目前我几年安服经历来说,从来没有太简单的问题,只有没有深入挖掘的需求,这一块需要从安服实施的目的来思考,我们行事都应该有一个目的,或者说目标,渗透测试,互联网资产发现,漏洞扫描,网站监测等是为了解决资产在安全检测能力下的评估,一个安全服务内容实施必定需要一个目的去支撑,如果无目的的做安服实施,那么要么安服太简单,要么划水划到腻。

安服太好了

安服也不能解决所有问题。因为没有任何方案和办法可以永久解决一个问题或者一个场景,安服好是因为可以解决设备不能解决,安全资源不足下安全建设的问题,但并非是万能药。

对安服理解的深度不够导致认为安服谁都可以做,的确谁都可以去实施安服,尤其是在后场有足够炮火支援的情况下,安服人员简直无所畏惧,但一定能把安服做好么?我评估一个安全服务人员在安服成长的可能性的时候,其实并不是他有多厉害,技术多牛,而是输出,能够在良好的安全素养下对安全需求方需求的输出,现阶段安服主要分技术和咨询,对应安全需求方安全技术建设和安全管理建设(人员建设等),我时常把自己当成甲方人员去思考,思考一个问题的解决是否是最佳的,一个需求的实现能否优化,现阶段的安服实施和安全规划,安全建设,安全运营,安全治理能否匹配,安服实施后的最后能给安全需求方带来什么不一样的体验。

安服太好了,是因为她接纳性和容忍度高,没有强势的门槛去限制你,但如果你以为所有人可以做好安服那就存在偏见了,安服多,好安服少,不要在舒适区做安服。

0x02 成长

这里我不会提供所谓的成长路线,因为安服实在是太大了,大到只要有需求就可以有服务,既然如此,深挖比广铺的方式要好很多;我们尽可能的精于一事,而不是一事不精,从单一的安全服务解决方案,解决办法再扩展到更多更高的解决方案,通常根据安服的覆盖和安全建设角度来思考,安全服务可以从以下角度进行成长:

1、体系化的安全规划:通过学习监管,法律法规等合规要求,并提供详细建议和咨询的人员,这类人员可以让企业在法律,合规上如鱼得水,但是缺乏安全技术的支持,需要对安全技术有一定的把握和理解,如果考虑安全技术规划,那么需要对网络架构,应用架构,甚至业务架构有一定的了解和熟悉,从而规划出适合整体 IT 规划,业务规划下,现有网络,应用架构的安全架构;

2、从阻拦,检测,预测,响应下的安全建设角度思考:需要对安全能力有着足够的理解,同时对安全建设,安全服务内容涉及的技术和研究内容有所掌握,这里是解决问题的主要能力,所以需要对漏洞挖掘,应急响应,样本分析,威胁情报,入侵检测等技术有着一定了解,不说能够自己造轮子,至少要能够使用轮子,或者在已有基础上去更新策略和安全防护水平;

3、从安全运营角度的安服:主要是态势感知和全流量分析,这块内容主要对网络结构,各网络设备的功能和安全防护架构有一定的了解,在此基础下部署全面监测,持续监测平台,并不断的进行分析,运营,优化,调整;

以上是安全服务的常见思路,接下来是secwiki的乙方安全服务工程师路线参考:

https://www.sec-wiki.com/skill/11

我有一个更详细和复杂的,后来想想还是算了,少即是多;

0x03 安服可以是什么?

安服可以是什么?那要看安全需求方需要什么?

经过这几个安服实施经历总结,安服主要有以下 4 个方面,安全规划,安全建设,安全运营,安全治理。为什么安服能够做这几个阶段或者方面的内容?

安服和安全规划

年底 10 月开始,安全需求方会开始对未来一年的安全投入做评估,规划明年一年的安全预算,期间很多内容可能会被砍,也有可能都会通过,安服我们可以做什么?安服实施后的数据,安全风险清单,安全技术,安全管理,人员评估,合规和监管要求,可以引导安全需求方在明年在人员,技术,管理等方面投入资源,进行规划,并协助安全规划落地,让预算和规划掷地有声。

此时常见的安全服务有安全技术风险评估,安全管理风险评估,安全规划,未来趋势研究等等

安服和安全建设

这里主要是在安全需求方使用安服来完成安全需求方的安全建设,所谓安全建设就是通过一系列安全控制,安全技术,安全管理的活动来工程化体系化实现安全在检测,阻拦,预测,响应下的安全能力增长。所有和安全防护,阻拦,检测,响应,运营相关的平台,体系搭建,发布,维护,运营前期都可以算是安全建设,维基百科并没有给我们更多的提示;同时,我们可以把安全建设分成四大块:基础安全建设,应用安全建设,数据安全建设,业务安全建设;通常会通过 CMMI 的 5 个级别(Ⅰ初始防护(初始状态),Ⅱ 基础管理(防御和处理),Ⅲ 充分定义(合规驱动),Ⅳ 量化控制(主动防御),Ⅴ 持续改进(自适应安全))来评估安全能力,与其说安全建设,不去说是安全能力建设,安服正是安全能力赋能的过程,同时是安全服务实施掷地有声的过程,也是最为关键的过程。一个好的安服人员应该是能够协调安全需求方,安全服务方双方资源,最有效的实现安全问题解决的安服人员,通过将资源落地最后实现安全能力增长的过程。

关于安全建设常见的安全服务有红蓝对抗,应急演练,渗透测试,就是通常的说千遍不如打一遍。

最后安服是促进安全能力内在增长的过程,也就是内生安全,我曾在黄哥的企业安全沙龙上听到一个词:常态化护网,护网一两个月都受不了了,你跟我说每天都护网,我才不干,这里说的常态化护网需要长期在安全建设上苦下功夫,当安全能力能够抵抗 80% 以上的风险时,常态化护网从技术上是可以实现的,剩下就需要不断的培养和宣贯。

安服在安全建设中如果能够促进安全能力内生,那安服的功效的基本上生效了一半。

安服和安全运营

安全行业大佬常说安全运营是解决安全问题的最后一公里,elknot 师傅也给了安全运营的一些建议,这里我就安服在安全运营的下功能和思路简单提一下,毕竟现在这是个风口,也是一个坑。

先说说自己对于安全运营的看法。

安全运营在于对已有安全风险控制,安全管理等手段联合资源,不断调整,适应当前阶段下安全能力优化的持续过程。

安全服务在其中可以做到很好的促进,安全服务走着安全服务方的后端资源,同时对于安全需求方的需求能够较好的把握,协调资源,调整重心去面对未来趋势下安全对抗的风险和威胁。同时安服能够收集安全服务活动下的所有非敏感数据,针对安全检测,阻拦,预测,响应能力提供不同的指标和方向。

安服和安全治理

之所以没把安全治理放在安全运营一部分,主要是安全运营主要针对安全规划,建设后的一些持续化改进思路,安全治理是单纯的对现有安全问题进行解决,仅仅是提出问题,解决问题,也便于后续对安全问题进行记录,常见的安全治理下的安全服务有账号安全治理,服务风险治理,双因子认证,访问控制治理,敏感数据泄露治理,供应链安全治理等等,我又叫这个方面的安服叫专题整治,协助安全需求方对于细粒度的安全风险进行控制。

0x04 期望

改变思维

在这里我不提什么重构安全服务的大理论,就像再说一说安服的目的和初衷;安服的核心还是解决方案,或者说安全的目的是为了解决风险问题,我们做事都需要有明确的目的去指引我们前进,安服也一样,当你决定把安服当成一个方案,一个办法去解决问题的时候,它将变得多种多样,它将不再是固定的安全服务实施内容,而是激活脑洞的办法和方案。

居安思危

没有永远的红海,也没有永远的风口,安服只是一段时间的解决办法,在需求和市场激活的方案,但没有任何的方案可以永远适配,除非它本身不能解决场景问题,说这个的目的是什么?

安服目前依赖的是安全人员的素养和工具流程下的解决办法,如果技术突破了专家经验,人员素养的问题时,安服人员将面临着清洗,当然这种情况短期不会出现。未来,人工智能一定会清洗很多行业,安服人员是否也会面临着失业呢?现在一些走在前面安全服务方开始在研究机器学习人工智能下的安全落地,图,神经网络和渗透测试的碰撞,自动化巡检和人工巡检,样本分析和高级沙箱,甚至强人工智能和安服实施,现在安服人员还是缺口,尤其是有经验有素养有技术的安服人员,未来也会以这批独立解决问题的安服人员为核心,那么我们是不是应该居安思危,不断提升自己的安全素养,安全技术。走出自己的舒适区,不断的挑战新的技术和思路。

沉淀

最近开始培养人去给更多的客户提供良好的安全服务,由于我历史工作原因吧,我更喜欢对接单一客户去专门服务单一客户,这样专注而有效,这类服务的大多数人员都是在现场去直接提供服务和解决办法,协调资源,同时也不会有人一直盯着,那么就需要我们自觉的去沉淀,我建议一个安服人员最好就是和接口人在一块,这样才能快速获得需求,避免隔楼效应,同时工作的时间我建议是4:1,即项目内容实施4天,1天思考和总结,要不断的停一停,总结归纳。

操守

当一个安全需求方将安全交给你的时候,也正是一种信任,这种信任难能可贵,需要我们通过一系列的自我要求去持续维护下去,像安服九不准,禁止非授权安服实施和安全变更,让安全服务落地符合安全需求方要求,并遵守需求方流程和制度。

不知不觉写了这么多,早就想讲讲自己在安服的看法,也不希望安服被娱乐化,一个真正的安服应该站在安全需求方角度,协调安全需求方和安全服务方资源,同时对安全解决方案能够进行量化和评估的人员,安服只是一种名称或者形式,真正在核心的应该是解决方案,而不是报告本身,你写再多的报告也没有一个解决办法有效,真正的安服不应该专注于报告数量,而是报告的质量,如果这份安服报告或者方案对于未来安全能力建设没有一丝的帮助,那么这份安服工作和产出是不是应该优化和调整,现在很大一部分的安服可能觉得自己廉价或者说没有意义,是因为安服本身没有意义,还是因为自己使其没有意义;这些情况不得而知;很多时候,我们需要给自己所做一个方向,然后朝着这个方向前进,对于安全服务方来说,应该基于安全需求方的需求去提供安全服务,这种服务可以是对内,也可以是对外;总之就是不要主动把自己放到一个尴尬的位置,你如果觉得安服不能实现价值,那就做点有挑战的事情,比如安全服务解决方案,安全服务运营,甚至安全服务开发等等,所有的事情并不是一开始就有的,只有你走出去才会出现;

安服究竟是什么?

安服是安全服务方基于安全需求方需求的解决方案。

现阶段一个好的安服难能可贵,有想法通过安全服务解决问题,提供安全解决方案的联系我,欢迎加入。

写于 2020 年第一次出差的一个夜晚!

正本清源:安服究竟是什么?

本文始发于微信公众号(信安之路):正本清源:安服究竟是什么?

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: