那年那观星那些事

那观星那些

决定写这篇文章的时候正值庚子年的倒数第二天,这个2020年诸事繁杂,很多小伙伴决定在京过年所以节前前所未有的忙碌,连续和老板、投资人、媒体、市场、研究中心轮番儿的讨论,总结这些年来的路径和思路,我突然萌生了写一篇文章来总结一下这些年我们走在资产管理的路上,主动的被动的踩过的那些“坑”的想法

取了这个标题,是想致敬那年那兔那些事,希望我们能和先辈一样,面对多么艰苦的条件都能够无所顾忌,勇往直前。谨以此文献给四年来帮助过我们成长的客户,和一起流过汗、加过班、一起奋斗一起拼搏的小伙伴们

一、资产管理的伊始

2016年,观星的第一个资产相关的需求,来自于互联网金融行业的一个客户。最开始获得这个客户的关注是依靠的我们安服团队的渗透能力,客户找了十来家公司做渗透测试,其中并不缺乏一些以渗透能力著称的大厂,并准备通过渗透测试结果选择乙方。说是渗透测试,但其实更类似于HW演练,要求不限任何手段模拟攻击,我们当时安服团队的头儿(现在是研究中心的头儿)亲自带队下场,成绩名列前茅——成功的控制了近千台服务器,并拿到了核心数据库操作权限。

通过安服能力,产品第一次接触到了这客户,由于客户处于超高速的发展期,为了最大成效的保障安全,客户向我们提出希望能够对他们的所有资产每天进行一次检测,发现新增端口,以便让他们能够快速获悉上线业务,我们也基于他们的需求开发了第一版观星台,一个SaaS化版本的观星台当时为了保障和用户的高频沟通,每周一的上午我都会准时蹲守在用户楼下,等他们开完早会一起探讨产品的使用情况,并快速迭代上线。

现在回想这一幕,总觉得充满了宿命般的戏剧感,以此为序幕,我们也走上了资产这条“不归路”,而且也从此确立了我们在资产上的路线。

半年后,满怀信心的我们怀揣着观星台1.0产品,前往深圳探访金融客户,届时我们对金融行业并没有太深的了解,也并不清楚互联网金融的需求其实更偏向于互联网,并非金融。

正如你们所能想象的,我们几乎可以说是折戟而归,探访的数十个金融客户,愿意试用的并不算多,甚至有客户斩钉截铁的和我们说:涉及到业务、责任人这些敏感数据,绝对不会放到saas化的平台上。

现在来看,当时在创业初期,选择用SaasS的产品形态,和我们所选择的资产管理这条路径确实存在一些冲突,尤其对于金融客户来说更难以接受。同时在那个时间点,资产的需求并不是十分普及,SaasS平台适用的监管客户和中小型客户也并不愿意将预算放到资产这个方向上

图片包含 图表

描述已自动生成

附图:观星台1.0版本

细粒度资产管理

虽然SaaS版本的尝试可以说是失败了,但借着这个产品,我们接触到了有这方面需求的真实客户。在交流过程中,我们很快就明白了我们产品(观星台)的核心理念:产品是为了解决用户的问题,安全ToB产品的表层需求是发现安全问题,中层的需求是形成管理闭环,深层的需求是实现安全价值。资产发现并不是用户的真正需求,建立资产管理体系,确保业务稳定运行,实现安全价值,才是客户的真正需求。

本着用户第一的原则(其实当时并没有清晰的“用户第一”的概念,只是一个模糊的想法,2017年我们很快就做出了决定:贴着客户走,重构观星台,打造私有化2.0版本。

坦白来说,这个决定对我们来说并不轻松,当时公司的财务情况也确实很糟糕,几乎可以说是押上企业的命,有一个月要不是团队伙伴从家里拿了10W,那个月的工资就要不够发了孤注一掷的决定在团队内也引发了巨大的质疑声、研发、技术、甚至产品团队都在打退堂鼓。但我们依旧咬着牙走下来了

现在回忆当时的路,得益于这个战略,所有人坚定了唯一的信念——迈不过这个山坡,以后遇到困难都不会坚持,只有坚持,才能带来成果。经过两次长时间的封闭研发,前后经过16个月的上线打磨,我们终于拿下了这个在行业里面信息技术水平第一的客户标杆。我们在三年前做的细粒度资产管理,确实非常难,但直到现在也没有哪家安全资产管理产品可以轻易超越。

回忆当时我们做了什么呢?

细粒度的数据级权限控制,当时这个客户许多下属分子公司,是个大型集团用户,需要能够支持多子公司多部门的资产报送、编辑管理需求,为了实现这个诉求,我们设计了灵活的层级权限,能够支撑到三级乃至四五级管理架构下的权限管理。

细粒度的责任归属记录、关联记录等为了能够实现用户互联网地址管理时,业务共享场景下不同端口归属不同业务的的归属记录,我们将业务关联做到IP+端口级别,还支持分别记录资产责任人、业务责任人、部门/子公司,以及内网对应关系的记录,我们认为这些细粒度的责任归属能够帮助用户在重保场景下快速定位,第一时间做出应急。

我们做的资产管理并不限于此,比如我们还做了资产全生命周期变更感知来应对端口不变业务变更的场景说实话,对比于工具性平台,这些细粒度的关联和权限控制让我们的产品变得比别人家更重,开发起来难度更高。但客户的认可和帮助一个个客户建立资产管理体系的过程,让我们觉得这一切是值得的。因为我们的初衷从来也没有变化过啊,一直是帮助客户建立自己的资产管理体系,从而体现安全价值。

人在玩电脑

描述已自动生成

附图:2017年封闭

从IT资产到数字资产

还记得我上面提到的互联网金融客户么?当时客户给我们提出的一个需求就是监控在Github上是否存和他们相关的代码,最开始其实不是太理解这个需求,后来我们安服团队给我看了github上都能找到什么东西才真的理解了安全这一行有多难干,任你纵深防御PPDR,抵不过一个github上传地址和用户名密码。

Github只是其中的一个维度,后来我们见了更多这样的事情,有某大行的用户名密码直接上传到网盘的、有小程序API直接明文传输用户信息的,让我们越发理解了安全这个东西既要广,又要深,任何一个点没有注意到都会成为攻击点,安全部门需要关注的资产开始不局限于传统的IT资产,git上上传的代码、文库网盘里上传的敏感文件、APP、公众号小程序、暗网交易等等都是用户关注的资产维度,单独做一个IT资产发现远远不够。

于是我们重新梳理了我们资产的定义,用了“数字资产”这个词语,也是在2019年的ISC大会上,我们首次对外定义数字资产,并提出了数字资产管理的概念。2020年的ISC会议上,我们提出了空间泛化的思路,认为当前的网络空间里远远不止传统IT资产,代码、数据、社交账号、供应链等等都是网络空间的组成部分,真正的网络空间测绘是泛空间测绘。

 

四,扫描速度的踩刹车

2019年,随着平台客户规模的扩展,观星台不但用于用户外网,也开始在逐步用于用户内网。内网和互联网资产的巨大差异也浮出水面,我们碰到了300并发就会扫死的wiki,也碰到过7年前一扫就挂的老旧防火墙有一次在用户内网扫描时影响到了用户的业务,我们CEO、CTO、运营的头儿、测试的头儿全员前往用户现场给客户领导致歉。那时互联网空间测绘大家都做的很粗暴(包括我们),为了追求速率采用异步扫描方式,当在客户处导致业务宕机客户叫停扫描的时候,发现分布式+异步的模式根本暂停不住

天平的一边是扫描速度和底层任务逻辑的改造成本,另外一边是客户“不能导致业务中断”的基本需求。我们开会讨论了很多轮,但最后还是觉得产品永远无法脱离用户存在,不给用户带来问题,帮助客户解决问题实现价值,才是我们应该做的事情。

于是我们踩了刹车,产品新功能开发的刹车实现了扫描任务的即时暂停和断点续扫。为了做到这个,我们确实牺牲了很多东西,比如扫描速度,这其实给我们带来了很多质疑,我们不止一次的在客户侧做多产品测试的时候,到:“为什么同样一个C段全端口扫描,友商只需要十来分钟,你们要两倍的时间,是不是你们技术不行?”

其实不是的,是我们的技术初衷和运用场景不同,他们适用的是网络空间测绘的快速探测,我们适用的是对脆弱的企业内网环境小心翼翼的检测,为了保障用户业务的稳定进行,我们在踩着刹车扫描

后来,为了弥补扫描时间较长和有些内网资产太过脆弱的问题,我们还实现了被动资产发现以及主被动结合的扫描方式,通过流量的方式,将对用户业务的影响降到最低,同时我们还把这个模块的基础功能开源了,来帮助用户尽可能的降低资产的扫描量。

,新时代的到来

其实在资产管理上,我们远远不止做了这些努力和尝试,比如分布式能够同时支持隔离网络和大型网络中多节点的任务调度能力、比如建立能够帮助用户在HW前发现“易混淆资产”的“疑似资产”能力、还有建立了一整套的从0day漏洞曝光到快速资产匹配、poc检测的共享机制等等。

最近和投资人和市场聊天,最经常被问到的问题就是你们和其他资产厂商有什么区别,其实我们做的这些事情就是答案——我们解决的一直是用户的资产管理问题,而不是网络空间测绘问题,我们关注的是资产的归属判断,资产的变化跟踪,资产管理体系的建设,和客户安全价值的实现。

2021年对我们来说是将会是非常关键的一年,观星将在这一年实现从1-N的裂变,突破现有能力和产品;做到更全、更快、更准;关注新的资产维度;踏足新的行业。未来的路上皆是变化,但始终不变的,是我们“用户第一,让安全管理更简单”的本质和初心。

让我用追梦赤子心里的一句歌词来做个结尾吧:

“继续跑 带着赤子的骄傲

生命的闪耀不坚持到底怎能看到

与其苟延残喘不如纵情燃烧吧

为了心中的美好 不妥协直到变老”

 

2021年3月31日 11:14
首页    那年那观星那些事