选择在不同的维度做防御

攻击的方法千千万万,封堵同一个安全风险的防御方法往往不止一种,如何选择性价比最高的手段是甲方安全从业者需要权衡的。

技术实现维度场景

在纵深防御的概念中(参考技术篇第一章)企业安全架构是层层设防,层层过滤的,常见漏洞如果要利用成功需要突破几层限制,所以退一步对防御者而言有选择在某一层或某几层去设防和封堵的便利,比如SQL注入,治本的方法当然是代码写对,治标的方法WAF过滤,中间的方法SQL层过滤,从效果上说治本的方法固然最好,但在现实中总归会遇到各种各样的问题而无法全部选择最安全的解,最后是退而求其次,还是选择某一层或者某几层去防御需要整体考虑。比如SQL注入如果在HTTP层面去解决无论是静态规则还是机器学习都需要对抗HTTP编码的问题,不是解决这个问题ROI最佳的点,但是在SQL层面,一切SQL语句都是真实的。现实生活中唯一的问题只是你能不能在最佳的点上推动解决方案。

“一题多解”的场景

假如同一个问题有>1种解决方案,可能会因场景不同而面临选择。比如对于SSH蠕虫的暴力破解,你可以选择(1)使用证书、(2)选择外部防火墙上关闭22端口,只通过堡垒机登录,(3)修改sshd监听非标准端口(4)修改sshd源代码对源限制,只接受可信的客户端地址(5)使用类似fail2ban这样的工具或自己写shell脚本,或者所谓的HIPS的功能。乍一看有的做法比较小众,有的则属于偏执狂式的。1,2,5属于大多数人都认同的普遍的做法,4和5看上去都比较小众,有的人认为可能不适合用作生产网络,其实要看场景。对于大型互联网公司内部自用而言:4和5其实都成立,尽管偏离了业界标准,但只要在公司内部的自治生态里做到“一刀切”就可以,业界普遍是sshd跑在22端口,你可以让公司内部的都跑在50022端口,只要公司内部的服务器全都维持这个统一策略,但是这个方案价值不大的地方在于这种信息不对称很容易被打破,你花了那么大力气让运维们都去连50022端口了,但攻击方很快就能知道,然后努力就白费了。而对于开源软件的修改,如果基础架构研发比较强大,Linux、Nginx、sshd、MySQL这些全都可以是改过的私房菜,加点有意义的安全功能也未尝不可。不过中小型公司不需要考虑这一点,自研毕竟是有门槛和成本的。假如场景切换到公有云给租户用的环境,这样干就不合适了,你还是应该提供跟业界兼容的标准运维环境,在标准运维环境之上提供额外的保护。

跨时间轴的场景

对于涉及跨时间维度的防护,典型的场景包括shellshock这样的漏洞公布时,各厂商在第一时间分析漏洞评估影响,这种影响是多层面的,不只是说可能拿到什么权限,还包括影响线上系统的哪些组件,这些组件的实时在线要求,修复漏洞会不会导致关联服务不可用。每一个漏洞修复的过程都是攻防双方和时间赛跑,攻击者尽量在厂商没有修复之前寻找利用点并发动渗透,而厂商尽可能在没出POC时赶紧把洞补了。在这个时间窗口中,甲方安全团队需要考虑的就是跨时间维度上的布防。出补丁之前是不是就干等不作为呢,显然不是的,细心的人会发现老牌安全公司的漏洞通告的解决方案里通常都会有一条,叫做“临时规避措施”,经验不足的团队是不会写上这条的。修不了漏洞时可以采用一些治标的补救性措施,比如对有漏洞的页面做访问控制,只允许有限的src.ip访问,比如在前端的WAF/IPS设备上加规则过滤对应的恶意请求,或者临时性的去掉一些权限,或者干脆关掉某些功能,但凡你想得到的通常总能找到临时规避方案,即便是有了补丁升级也不是立即完成的,在大型互联网生产网络里,全网push完一个补丁是需要不少时间的,有可能一个礼拜都弄不完,而且修复过程中要考虑服务可用性需要使用灰度和滚动升级的方法,比如修复前先把负载均衡上的流量切换到standby节点,然后对master节点的服务器打补丁,打完再把流量切回去,然后对standby节点的服务器打补丁……,打完补丁后把临时防御措施再“回滚”掉(有价值的保留,核心设备上不建议留太多臃肿的规则),然后把特征加入全流量和主机IDS。回顾整个时间轴的防护措施依次是:临时性规避措施–push补丁/根治措施—取消临时性措施—添加常态性的特征检测措施—检测到漏网之鱼—继续上述过程,这个过程离最佳实践实际上还差了一个环节,不过这里只是用来说明开头提到的那个问题故而不展开了,后面会介绍对于一个漏洞修复是否需要上升层次的问题。

风险和影响的平衡

假如你遇到一个安全问题是这样的:vlan数目不够,vxlan又不可用,提交问题后研发的反馈的方案A是如果要彻底修复则需要新增一个dhcpd的安全功能大约包含10000(loc)即1w行代码,此时产品线又处于整体加班加点赶工大版本的状态,有人提出了方案B做IP/MAC双向绑定的缓解性措施,但这样的结果很可能是客户觉得太麻烦,而且配置一多容易出错,此时你想到了一个折中的办法 方案C:给大客户单独vlan,若干小客户共享一个vlan,这样的好处是不需要太多成本,风险降低到可控,客户可以接受。如果选择方案A是不是更好?这个要看,假如这1w行代码只是用来临时的解决这个问题,显然ROI比较低,但是如果后续的版本本来就要加入这个功能,不妨考虑一下。又如果后续版本不需要这个小众的功能,研发心里其实本不打算去开发的,说不定下次告诉你说要2w行代码,然后你push到CTO那里也说不清风险到底多么严重,就会陷入僵局。风险缓解的原则是在以下三者之间做最大平衡:1)风险暴露程度;2)研发运维变更成本;3)用户体验的负面影响。

修复成本的折中

一个安全漏洞的修复如果研发说要开发1周,另外一个方案是运维改一个服务器配置,而你其实心里知道在WAF上加条规则就能过滤,只不过你怕被绕过心里对这个措施不是特别有底气。对于这个场景我也不打算直接给出答案,但通常情况下改产品的成本是最高的,成本最高的往往不容易推动,推不动就无法落地,最后就是一堆安全问题。

Amazon有一个研发理论,用一种T-Shirt Size 估计的方式来做项目。

产品经理会对每一条需求评估上业务影响力的尺寸,如:XXXL 影响一千万人以上或是可以占到上亿美金的市场,XXL,影响百万用户或是占了千万金级别以上的市场,后面还有XL、L、M、S,这样下来。

开发团队也一样,要评估投入的人员时间成本,XXXL表示要干1年,XXL干半年,XL干3个月,L干两个月,M干一个月,S干两周以下。等等。

于是,

当业务影响力是XL,时间人员成本是S,这是最高优先级。

当业务影响力是M,时间人员成本是M,这是低优先级。

当业务影响力是S,时间人员成本是XL,直接砍掉这个需求。因为是亏的。

当业务影响力是XXL,时间人员成本是XXL,需要简化需求,把需求简化成XL,时间人员成本变成M以下。

安全其实也类似,风险和修复成本去比较,在坚守底线的基础上选择最优解。

 

综上,大家可以发现最优解往往不一定是最安全的解,市场上乙方公司渗透测试报告中提的修复方案有些也是无法实施的,很多批判企业安全做的不好的帽子们,有机会真应该到企业里体验一下,企业安全岂是找洞补洞这么简单的事。

参考资料

陈皓“加班与效率”http://coolshell.cn/articles/10217.html#more-10217

 

浅析大规模DDOS防御架构-应对T级攻防

导读

ddos-guide

DDOS分类

在讲防御之前简单介绍一下各类攻击,因为DDOS是一类攻击而并不是一种攻击,并且DDOS的防御是一个可以做到相对自动化但做不到绝对自动化的过程,很多演进的攻击方式自动化不一定能识别,还是需要进一步的专家肉眼判断。

网络层攻击

Syn-flood

利用TCP建立连接时3次握手的“漏洞”,通过原始套接字发送源地址虚假的SYN报文,使目标主机永远无法完成3次握手,占满了系统的协议栈队列,资源得不到释放,进而拒绝服务,是互联网中最主要的DDOS攻击形式之一。网上有一些加固的方法,例如调整内核参数的方法,可以减少等待及重试,加速资源释放,在小流量syn-flood的情况下可以缓解,但流量稍大时完全不抵用。防御syn-flood的常见方法有:syn proxy、syn cookies、首包(第一次请求的syn包)丢弃等。

ACK-flood

对于虚假的ACK包,目标设备会直接回复RST包丢弃连接,所以伤害值远不如syn-flood。DDOS的一种原始方式。

UDP-flood

使用原始套接字伪造大量虚假源地址的UDP包,目前以DNS协议为主。

ICMP-flood

Ping洪水,比较古老的方式。

应用层攻击

CC

ChallengeCollapsar的名字源于挑战国内知名安全厂商绿盟的抗DDOS设备-“黑洞”,通过botnet的傀儡主机或寻找匿名代理服务器,向目标发起大量真实的http请求,最终消耗掉大量的并发资源,拖慢整个网站甚至彻底拒绝服务。

互联网的架构追求扩展性本质上是为了提高并发能力,各种SQL性能优化措施:消除慢查询、分表分库、索引、优化数据结构、限制搜索频率等本质都是为了解决资源消耗,而CC大有反其道而行之的意味,占满服务器并发连接数,尽可能使请求避开缓存而直接读数据库,读数据库要找最消耗资源的查询,最好无法利用索引,每个查询都全表扫描,这样就能用最小的攻击资源起到最大的拒绝服务效果。

互联网产品和服务依靠数据分析来驱动改进和持续运营,所以除了前端的APP、中间件和数据库这类OLTP系统,后面还有OLAP,从日志收集,存储到数据处理和分析的大数据平台,当CC攻击发生时,不仅OLTP的部分受到了影响,实际上CC会产生大量日志,直接会对后面的OLAP产生影响,影响包括两个层面,一个当日的数据统计完全是错误的。第二个层面因CC期间访问日志剧增也会加大后端数据处理的负担。

CC是目前应用层攻击的主要手段之一,在防御上有一些方法,但不能完美解决这个问题。

DNS flood

伪造源地址的海量DNS请求,用于是淹没目标的DNS服务器。对于攻击特定企业权威DNS的场景,可以将源地址设置为各大ISP DNS服务器的ip地址以突破白名单限制,将查询的内容改为针对目标企业的域名做随机化处理,当查询无法命中缓存时,服务器负载会进一步增大。

DNS不只在UDP-53提供服务,同样在TCP协议提供服务,所以防御的一种思路就是将UDP的查询强制转为TCP,要求溯源,如果是假的源地址,就不再回应。对于企业自有权威DNS服务器而言,正常请求多来自于ISP的域名递归解析,所以将白名单设置为ISP的DNS server列表。对于源地址伪造成ISP DNS的请求,可以通过TTL值进一步判断。

慢速连接攻击

针对http协议,以知名的slowloris攻击为起源:先建立http连接,设置一个较大的content-length,每次只发送很少的字节,让服务器一直以为http头部没有传输完成,这样的连接一多很快就会出现连接耗尽。

目前出现了一些变种,http慢速的post请求和慢速的read请求都是基于相同的原理。

DOS攻击

有些服务器程序存在bug、安全漏洞,或架构性缺陷,攻击者可以通过构造的畸形请求发送给服务器,服务器因不能正确处理恶意请求而陷入僵死状态,导致拒绝服务。例如某些版本的app服务器程序存在缓冲区溢出,漏洞可以触发但无法得到shell,攻击者可以改变程序执行流程使其跳转到空指针或无法处理的地址,用户态的错误会导致进程挂起,如果错误不能被内核回收则可能使系统当掉。

这类问题效果也表现为拒绝服务,但本质上属于漏洞,可以通过patch程序的最新版本解决,笔者认为不属于DDOS的范畴。

攻击方式

混合型

在实际大流量的攻击中,通常并不是以上述一种数据类型来攻击,往往是混杂了TCP和UDP流量,网络层和应用层攻击同时进行。

反射型

2004年时DRDOS第一次披露,通过将SYN包的源地址设置为目标地址,然后向大量的

drdos

真实TCP服务器发送TCP的SYN包,而这些收到SYN包的TCP server为了完成3次握手把SYN|ACK包“应答”给目标地址,完成了一次“反射”攻击,攻击者隐藏了自身,但有个问题是攻击者制造的流量和目标收到的攻击流量是1:1,且SYN|ACK包到达目标后马上被回以RST包,整个攻击的投资回报率不高。

反射型攻击的本质是利用“质询-应答”式协议,将质询包的源地址通过原始套接字伪造设置为目标地址,则应答的“回包”都被发送至目标,如果回包体积比较大或协议支持递归效果,攻击流量会被放大,成为一种高性价比的流量型攻击。

反射型攻击利用的协议目前包括NTP、Chargen、SSDP、DNS、RPC portmap等

等。

流量放大型

以上面提到的DRDOS中常见的SSDP协议为例,攻击者将Search type设置为ALL,搜索所有可用的设备和服务,这种递归效果产生的放大倍数是非常大的,攻击者只需要以较小的伪造源地址的查询流量就可以制造出几十甚至上百倍的应答流量发送至目标。

脉冲型

很多攻击持续的时间非常短,通常5分钟以内,流量图上表现为突刺状的脉冲。

impulse-ddos

之所以这样的攻击流行是因为“打-打-停-停”的效果最好,刚触发防御阈值,防御机制开始生效攻击就停了,周而复始。蚊子不叮你,却在耳边飞,刚开灯想打它就跑没影了,当你刚关灯它又来了,你就没法睡觉。

自动化的防御机制大部分都是依靠设置阈值来触发。尽管很多厂商宣称自己的防御措施都是秒级响应,但实际上比较难。

网络层的攻击检测通常分为逐流和逐包,前者根据netflow以一定的抽样比例(例如1000:1)检测网络是否存在ddos攻击,这种方式因为是抽样比例,所以精确度较低,做不到秒级响应。第二种逐包检测,检测精度和响应时间较短,但成本比较高,一般厂商都不会无视TCO全部部署这类方案。即便是逐包检测,其防御清洗策略的启动也依赖于阈值,加上清洗设备一般情况下不会串联部署,触发清洗后需要引流,因此大部分场景可以做秒级检测但做不到秒级防御,近源清洗尚且如此,云清洗的触发和转换过程就更慢了。所以利用防御规则的生效灰度期,在触发防御前完成攻击会有不错的效果,在结果上就表现为脉冲。

链路泛洪

随着DDOS攻击技术的发展,又出现了一种新型的攻击方式link-flooding attack,这种方式不直接攻击目标而是以堵塞目标网络的上一级链路为目的。对于使用了ip anycast的企业网络来说,常规的DDOS攻击流量会被“分摊”到不同地址的基础设施,这样能有效缓解大流量攻击,所以攻击者发明了一种新方法,攻击至目标网络traceroute的倒数第二跳,即上联路由,致使链路拥塞。国内ISP目前未开放anycast,所以这种攻击方式的必要性有待观望。

LFA-ddos

对一级ISP和IXP的攻击都可以使链路拥塞。

多层防御结构

DDOS攻击本质上是一种只能缓解而不能完全防御的攻击,它不像漏洞那样打个补丁解决了就是解决了,DDOS就算购买和部署了当前市场上比较有竞争力的防御解决方案也完全谈不上彻底根治。防火墙、IPS、WAF这些安全产品都号称自己有一定的抗DDOS能力,而实际上他们只针对小流量下,应用层的攻击比较有效,对于稍大流量的DDOS攻击则无济于事。

以2015年年中的情况为例,国内的DDOS攻击在一个月内攻击流量达到300G的就将近10-20次,这个数值将随着国内家庭宽带网速提升而进一步放大。对于200~500G的攻击流量该如何防御,下来将展示完整的防御结构,通常可以分为4层。

ddos-4

这4层不是严格意义上的纵深防御关系,也不是在所有的防御中4层都会参与,可能有时候只是其中的2层参与防御。但对于超大流量攻击而言,4层就是防御机制的全部,再没有其他手段了。跟厂商们的市场宣传可能有所不同,大流量攻击的防护并不是像某些厂商宣称的那样靠厂商单方面就能解决的,而是多层共同参与防御的结果。

ISP/WAN层

这一层通常对最终用户不可见,如果只是中小企业,那这一层可能真的不会接触到。但如果是大型互联网公司,公有云厂商,甚至是云清洗厂商,这层是必不可少的。因为当流量超过自己能处理的极限时必须要借助电信运营商的能力。大型互联网公司虽然自身储备的带宽比较大,但还没到达轻松抵抗大流量DDOS的程度,毕竟带宽是所有IDC成本中最贵的资源没有之一。目前无论是云计算厂商,大型互联网公司向外宣称的成功抵御200G以上攻击的新闻背后都用到了运营商的抗D能力,另外像第三方的云清洗平台他们实际上或多或少的依赖电信运营商,如果只依靠本身的清洗能力,都是非常有限的。

近源清洗

目前如中国电信的专门做抗DDOS的云堤提供了[近源清洗]和[流量压制]的服务,对于购买其服务的厂商来说可以自定义需要黑洞路由的IP与电信的设备联动,黑洞路由是一种简单粗暴的方法,除了攻击流量,部分真实用户的访问也会被一起黑洞掉,对用户体验是一种打折扣的行为,本质上属于为了保障留给其余用户的链路带宽的弃卒保帅的做法,之所以还会有这种收费服务是因为假如不这么做,全站服务会对所有用户彻底无法访问。对于云清洗厂商而言,实际上也需要借助黑洞路由与电信联动。

云堤黑洞

相比之下,对攻击流量的牵引,清洗,回注的防御方式对用户体验的挑战没那么大,但是跟黑洞路由比防御方的成本比较高,且触发到响应的延时较大。

在运营商防御这一层的主要的参与者是大型互联网公司,公有云厂商,云清洗厂商,其最大的意义在于应对超过自身带宽储备和自身DDOS防御能力之外的超大攻击流量时作为补充性的缓解措施。

CDN/Internet层

CDN并不是一种抗DDOS的产品,但对于web类服务而言,他却正好有一定的抗DDOS能力,以大型电商的抢购为例,这个访问量非常大,从很多指标上看不亚于DDOS的CC,而在平台侧实际上在CDN层面用验证码过滤了绝大多数请求,最后到达数据库的请求只占整体请求量的很小一部分。

对http CC类型的DDOS,不会直接到源站,CDN会先通过自身的带宽硬抗,抗不了的或者穿透CDN的动态请求会到源站,如果源站前端的抗DDOS能力或者源站前的带宽比较有限,就会被彻底DDOS。

云清洗厂商提出的策略是,预先设置好网站的CNAME,将域名指向云清洗厂商的DNS服务器,在一般情况下,云清洗厂商的DNS仍将穿透CDN的回源的请求指向源站,在检测到攻击发生时,域名指向自己的清洗集群,然后再将清洗后的流量回源。

检测方式主要是在客户网站前部署反向代理(nginx),托管所有的并发连接。在对攻击流量进行分流的时候,准备好一个域名到IP的地址池,当IP被攻击时封禁并启用地址池中的下一个IP,如此往复。

以上是类Cloudflare的解决方案,国内云清洗厂商的实现原理都相似。不过这类方案都有一个通病,由于国内环境不支持anycast,通过DNS引流的方式需要比较长的生效时间,这个时间依赖于DNS递归生效的时长,对自身完全不可控。同时CDN仅对web类服务有效,对游戏类TCP直连的服务无效。

网上很多使用此类抗D服务的过程可以概括为一句话:更改CNAME指向,等待DNS递归生效。

DC层

Datacenter这一层的DDOS防御属于近目的清洗,就是在DC出口的地方部署ADS设备。

antiddos8000

目前国内厂商华为的Anti-ddos产品的最高型号支持T级高达1440Gbps带宽的防护。原理大致如下图所示,在DC出口以镜像或分光部署DDOS探针(检测设备),当检测到攻击发生时,将流量牵引到旁路部署的DDOS清洗设备,再将经过清洗的正常流量回注到业务主机,以此完成一轮闭环。

antiddos-DC

部署设备本身并没有太大的技术含量,有技术含量的部分都已经被当做防御算法封装在产品盒子里了。不过要指出的一点是,目前市场上的ADS盒子既有的算法和学习能力是有限的,他仍然需要人的介入,比如:

  • 对业务流量基线的自适应学习能力是有限的,例如电商行业双11大促日子的流量模型可能就超越了ADS的学习能力,正常流量已经触发攻击判定
  • 自动化触发机制建立在阈值之上,就意味着不是完全的自动化,因为阈值是一个经验和业务场景相关的值
  • 全局策略是通用性策略,不能对每一个子业务起到很好的防御效果,有可能子业务已经被D了,全局策略还没触发
  • 常见的DDOS类型ADS可以自动处理,但变换形式的DDOS类型可能还需要人工识别
  • 默认的模板策略可能不适用于某些业务,需要自定义

DDOS防御除了整体架构设计外,比较需要专业技能的地方就是在上述例子的场景中。目前在ADS设备里覆盖了3-4,7这三层的解决方案。

antiddos8000func

一般情况下ADS设备可以缓解大部分常见的DDOS攻击类型,相对而言3-4层的攻击手法比较固定,而7层的攻击,由于涉及的协议较多,手法变化层出不穷,所以ADS有时候对7层的防护做不到面面俱到,比如对CC,ADS提供了http 302,验证码等,但还是不能很好的解决这个问题。应用层的防护需要结合业务来做,ADS则在能利用的场景下承担辅助角色,比如对于游戏封包的私有协议,通过给packet添加指纹的方式,ADS在客户端和服务端中间鉴别流入的数据包是否包含指纹。

OS/APP层

这是DDOS的最后一道防线。这一层的意义主要在于漏过ADS设备的流量做最后一次过滤和缓解,对ADS防护不了的应用层协议做补充防护。比如NTP反射,可以通过服务器配置禁用monlist,如果不提供基于UDP的服务,可以在边界上直接阻断UDP协议。

互联网在线服务中最大的比重就是web服务,因此有些互联网公司喜欢自己在系统层面去做应用层的DDOS防护,例如对抗CC,有时这些功能也能顺带关联到业务安全上,比如针对黄牛抢单等。

anti-CC

实现方式可以是web服务器模块,也可以是独立部署的旁路系统,反向代理将完整的http请求转发给检测服务器,检测服务器根据几方面的信息:

  • 来自相同IP的并发请求
  • 相同ip+cookie的并发请求
  • 相同http头部可设置字段
  • 相同的request URL

然后保存客户端的连接信息计数表,例如单位时间内相同IP+cookie再次发起连接请求则此客户端IP的计数器+1,直到触发阈值,然后服务器会进行阻断,为了避免误杀,也可以选择性的弹出验证码。

以上是拿CC防御举了个例子,ADS设备本身提供了http 302跳转,验证码,Javascript解析等防御方式,尽管OS和应用层可以做更多的事情,但毕竟有自己去开发和长期维护的代价,这个收益要看具体情况。

链路带宽

增加带宽,大部分介绍DDOS防御策略的文章里似乎很少提及这一点,但却是以上所有防御的基础,例如第二层次的CDN实际上就是拼带宽,很多大型企业选择自建CDN,本质上就是自己增加带宽的行为。除了CDN之外,要保障DC出口的多ISP链路、备份链路,到下层机柜交换机的带宽都不存在明显的单点瓶颈,否则抗DDOS的处理性能够了,但是流量流经某个节点时突然把一个杂牌交换机压垮了,最后的结果还是表现为有问题。

对运维经验成熟的互联网公司而言,一般都有能容管理,对于促销活动,高峰时段的带宽,IDC资源的波峰波谷都有预先的准备,DDOS防御主要是消除这些网络方案中内在的单点瓶颈。

不同类型的企业

DDOS的防御本质上属于资源的对抗,完整的4层防御效果虽好,但有一个明显问题就是TCO,这种成本开销除了互联网行业排名TOP10以外的公司基本都吃不消。或者就算付得起这钱,在IT整体投资的占比会显得过高,付得起不代表这种投资是正确的。所以针对不同的企业分别描述DDOS缓解方案的倾向和选择性。

大型平台

这里的“大”有几层意思:

  • 公司很有钱,可以在补贴具体的业务上不“太”计较投入,对土豪来说只选效果最优方案
  • 公司不一定处在很赚钱的阶段,但IDC投资规模足够大,这样为了保障既有的投入,安全的总投资维持一个固定百分比也是非常有必要的,在IDC盘子很大的时候没必要省“小钱”
  • 与潜在的由于服务中断造成的损失比,DDOS防御的投资可以忽略不计

映射到现实中与这几条相关的公司:

  • 市值100亿美元以上互联网公司
  • 大型公有云厂商,IaaS、PaaS平台
  • IDC规模多少算大呢,这个问题其实很难判断,1w台物理服务器算多么,现在应该只能算中等吧
  • 利润比较高的业务,比如游戏、在线支付假如被DDOS的频率较高

对于IDC规模比较大又有钱的公司来说,防DDOS的口诀就是“背靠运营商,大力建机房”,在拥有全部的DDOS防御机制的前提下,不断的提高IDC基础设施的壁垒给攻击者制造更高的门槛,对于网络流量比较高的公司而言,抗DDOS是有先天优势的,因为业务急速增长而带来的基础设施的扩容无意识间就成了一种防御能力,但对于没有那么大业务流量的公司,空买一堆带宽烧钱恐怕也没人愿意。

对于比较有钱,但没那么多线上服务器的公司而言,自己投入太多IDC建设可能是没必要的,此时应该转向通过购买的手段尽可能的获得全部的DDOS防御机制。

中小企业

资源的对抗肯定不是中小企业的强项,所以追求ROI是主要的抗DDOS策略。第一种极度省钱模式,平时裸奔,直到受攻击才找抗DDOS厂商临时引流,这种方案效果差一点,绝大多数企业应该都是这种心理,得过且过,能省则省,也无可厚非,不过关键时间知道上哪儿去找谁,知道做哪些事。

第二种追求效果,希望有性价比。如果本身业务运行于公有云平台,可以直接使用云平台提供的抗DDOS能力,对于web类可以考虑提前购买云清洗厂商的服务。

不同类型的业务

不同的类型的服务所需要的DDOS防御机制不完全相同,所以不能直接拿前述4层生搬硬套。

Web

对于web类服务,攻击发生时终端用户可以有一定的延迟容忍,在防御机制上4层全部适用,大型平台的一般都是4层全部拥有,规模小一点的企业一般购买云清洗,cloudflare类的服务即可。

游戏类

Web api形式的轻游戏跟web服务类似,而对于TCP socket类型的大型网游,稍有延迟很影响用户体验,甚至很容易掉线。云WAF、CDN等措施因为是针对web的所在在该场景下无效,只有通过DNS引流和ADS来清洗,ADS不能完美防御的部分可以通过修改客户端、服务端的通信协议做一些辅助性的小动作,例如封包加tag标签,检测到没有tag的包一律丢弃,防御机制基本都是依赖于信息不对称的小技巧。DNS引流的部分对于有httpdns的厂商可以借助其缓解DNS递归生效的时间。

服务策略

分级策略

对于平台而言,有些服务被DDOS会导致全站服务不可用,例如DNS不可用则相当于全线服务不可用,对于强账号体系应用例如电商、游戏等如果SSO登陆不可用则全线服务不可用,攻击者只要击垮这些服务就能“擒贼擒王”,所以安全上也需要考虑针对不同的资产使用不同等级的保护策略,根据BCM的要求,先将资产分类分级,划分出不同的可用性SLA要求,然后根据不同的SLA实施不同级别的防护,在具体防护策略上,能造成平台级SPOF(单点故障)的服务或功能应投入更高成本的防御措施,所谓更高成本不仅指购买更多的ADS设备,同时可能建立多灾备节点,并且在监控和响应优先级上应该更高。

Failover机制

DDOS防御不只是依赖于DDOS防御的那4层手段,同时依赖于基础设施的强大,例如做分流,就需要多点异地灾备,mirror site & hot site & standby system,云上的系统需要跨AZ部署,这些可以随时切换的基础。把鸡蛋放在一个篮子里会导致没什么选择。

基础设施和应用层面建立冗余是技术形式上的基础,光有这些还远远不够,需要有与之配套的DRP&BCP策略集,并且需要真实的周期性的演练,意在遇到超大流量攻击时能够从容应对。

有损服务

在应用服务设计的时候,应该尽量避免“单点瓶颈”,避免一个点被DDOS了整个产品就不好用了,而是希望做到某些服务即使关闭或下线了仍然不影响其他在线的服务(或功能),能在遇到需要弃卒保帅的场景时有可以“割肉”的选择,不要除了“0”就是“1”,还是要存在灰度,比如原来10个服务在线,遇到攻击时我只要保底重要的3个服务在线即可。

补充手段

DDOS攻击的目的不一定完全是出于想打垮服务,比如以前在做游戏时遇到玩家DDOS服务器的目的竟然是因为没抢到排在第一的房间,这种因素通过产品设计就可以根治,而有很多应用层DDOS只是为了达成另外一种目的,都跟上述4层防御机制无关,而跟产品设计有关。所以防御DDOS这事得看一下动因,不能盲目应对。

NIPS场景

ADS本质上是一个包过滤设备,虽功用不同却跟IPS有点相似,之前也提到有时候需要提供全站IPS的虚拟补丁功能,ADS设备就可以充当这一角色,只是条目不宜多,只上有限的条目,下面的是NSFOCUS的ADS设备的规则编辑界面,payload可自定义

黑洞界面

一般安全团队能力尚可的话,可以通过运行POC exploit,然后抓包找出攻击payload的特征,编辑16进制的匹配规则,即可简单的实现人工定制。

破防和反制

从安全管理者的角度看,即便是拥有完整的4层防御机制也并非无懈可击,号称拥有400-500G防护能力的平台是完全有可能被打垮的,完全的防护能力是建立在人、策略、技术手段都生效的情况才有的,如果这些环节出了问题,anti-ddos的整个过程可能会失败。例如下面提到的这些问题:

  • 超大流量攻击时需要用到黑洞路由,但黑洞路由的IP需要由防御方定义和联动,“联动”的过程就是向上游设备发送封禁IP的通知,如果接口不可用,那么此功能会失效,所以ISP级的防御是有失效可能性的
  • CDN云清洗服务依赖于清洗服务商接管域名解析,如果云清洗服务商本身的DNS不可用,也将导致这一层面的防御失效,诸如此类的问题还有不少,这些抗D厂商自身并非无懈可击
  • ADS平时不一定串联部署,但攻击发生引流后一定是业务的前端设备,假如这个设备本身存在DOS的可能,即使是触发了bypass也相当于防御完全失效了,另一方面策略下发通常是ADS设备跟管理节点互通,如果管理节点出现可用性问题,也将导致ADS防御的一系列问题。
  • 超大流量攻击需要人工干预时,最基本的需求是安全或运维人员能在办公网络连接到ADS的管理节点,能远程运维ADS设备,如果此时办公网络的运维管理链路出现故障,不仅切断了人员操作,还会把现场应急的紧张气氛提升一个量级,使人更加手忙脚乱。

以上并不在于提供新的攻击的思路,而在于向anti-ddos方案的制定者提供另类视角以便于审视方案中的短板。

立案和追踪

目前对于流量在100G以上的攻击是可以立案的,这比过去幸福了很多。过去没有本土特色的资源甚至都没法立案,但是立案只是万里长征的第一步,如果你想找到人,必须成功完成以下步骤:

  • 在海量的攻击中,寻找倒推的线索,找出可能是C&C服务器的IP或相关域名等
  • “黑”吃“黑”,端掉C&C服务器
  • 通过登录IP或借助第三方APT的大数据资源(如果你能得到的话)物理定位攻击者
  • 陪叔叔们上门抓捕
  • 上法庭诉讼

如果这个人没有特殊身份,也许你就能如愿,但假如遇到一些特殊人物,你几个月都白忙乎。而黑吃黑的能力则依赖于安全团队本身的渗透能力比较强,且有闲情逸致做这事。这个过程对很多企业来说成本还是有点高,光有实力的安全团队这条门槛就足以砍掉绝大多数公司。笔者过去也只是恰好有缘遇到了这么一个团队。

安全需要向业务妥协吗

安全行业5年以下的新人得到的灌输基本都是“安全不可或缺”,老兵们可能也有点“看破红尘”的味道,觉得高层重不重视安全也就那么回事。对乙方来说高声呼吁安全的重要性哪怕是强调的有点过头也可以理解,因为是赖以生存的利益相关者,靠它吃饭,影响股价。而对于甲方,实际上要分几种,第一类认为安全压倒一切,且心口一致。持有这类想法的实际细分为两种人,第一种对安全行业涉猎不深,还停留在原始的执念阶段,第二种人的思想可以表达为“业务怎么样与我无关,只要不出安全问题,业务死了都无所谓”,这两种从表象上看都属于第一类,而第二类人口头唱安全重要,但心里还是会妥协。以上这些都是甲方安全团队中形形色色的区别。

撇开上述观念,先看安全管理的本质是什么?安全的本质其实是风险管理,绝对的安全可能吗,说绝对安全本身就是个笑话。就像袁哥说的哪怕是Fireeye这样的公司也一样会被APT,原因是攻防不对等,防御者要防御所有的面,而攻击者只要攻破其中一个面的一个点就可以了,公司几千人的客户端行为不是安全管理员能决定和预测的。在所有的面上重兵布防可不可以,理论上可以但实际绝对做不到。接近于绝对安全的系统是什么样的?尽可能的不提供服务、提供服务也只提供最单调的数据交互模型,尽可能少的表现元素,那样的话还是互联网吗,还有用户体验可言吗?而且安全和成本永远要追求一个平衡。假设一个大中型互联网公司的安全建设成本从0-60分需要1000w60-80分需要2000w80-90分需要5000w90-95分需要2亿,这种边际成本递增是很多公司无法承受的,只能追求最佳ROI,虽然最佳ROI难以衡量,但绝大多数人的理性决定了不会拿出收入的50%去投安全建设。

既然安全建设的本质是以一定的成本追求最大的安全防护效果,那一定是会有所妥协的。于是反过来揣摩一下那些说宁可业务死也要做安全的观点的初衷是什么呢,也许你猜到了,怕担责任!因为业务死了安全团队不担责任,他们可以说“你看安全不是没出问题嘛!”这固然是一种保护自己的方法,但是从公司的角度看这就有待商榷了,我认为安全本质还是为业务服务,如果业务死了,即使安全做的再好也没价值,更准确一点说,安全需要为业务量身定制,如果业务要轻装上阵,你给他重甲也不行,只能穿防弹背心。安全做的过于重度都是不合适的。相对而言第二类人拥有更加积极的心态,坚持原则又懂得给业务让路,只是要把握好分寸,避免自己的好心被人利用,成为安全问题不整改的免责窗口,那样就事与愿违了。

安全做的不称职的表现,除了“无视业务死活”,还包括:用户体验大打折扣,产品竞争力下降;公司内部流程大幅增加,严重影响工作效率;限制太多员工满意度严重下降,人员流失;规章制度太多,以至于公司文化显得不近人情……这些都属于安全做过头的表现。

有的人出发的太久,以至于忘了初衷是什么。

那么哪些可以妥协,哪些必须坚守底线呢?高危漏洞,有明显的利用场景,不能妥协。重要的安全特性,比如公有云中的VPC,底层缺少一个安全特性,直接会导致安全建设的上层建筑失去了“地基”,整个都不牢靠了,这种还是要坚持,可以不精致,但必须有。

对于不痛不痒的漏洞,以及待开发的安全功能,如果开发周期很长,受众群体很少,使用该功能的用户比例极少,边缘性产品,只影响某个中间版本到下个版本被其他机制完全取代了,诸如此类的情况可以考虑酌情妥协。当然这还会涉及到另一个话题在不同的维度解决问题,这个之后再展开。

妥协并非退让,而是大局观,试想公司业务没有竞争力时,做安全的一样面临窘境,无论如何都要看主营业务的脸色,与其被动跟随不如快出半个身位。

 

如何推动安全策略

这是一个在安全负责人的面试中经常被提及的问题,也是在现实生活中甲方团队天天面对的问题。如果你不是正巧在面试,那怎么回答这个问题其实不重要。

首先,推动安全策略必须是在组织中自上而下的,先跟高层达成一致,形成共同语言,对安全建设要付出的成本和收益形成基本认知,这个成本不只是安全团队的人力成本和所用的IDC资源,还包括安全建设的管理成本,流程可能会变长,发布链条会比过去更长,有些产品可能会停顿整改安全,安全特性的开发可能会占用正常的功能迭代周期,程序员可能会站起来说安全是束缚,这些都是需要跟各产品线老大达成一致的,他们要认同做安全这件事的价值,你也要尽可能的提供轻便的方法不影响业务的速度。在规模较大的公司,只有自上而下的方式才能推得动,如果你反其道行之,那我估计安全团队多半在公司是没有地位的,顶多也就是在微博或者技术博客上有些外在的影响力。往下攻略去影响程序员和SA/DBA的难度肯定比往上攻略去影响CXO/VPs的难度小,但如果一开始就选择一条好走的路,实际对安全团队来说是不负责任的,作为Leader自己就是要很苦逼的把这一课给过了,否则安全团队就只能做些补洞、打杂、救火队长的事。

战术层面,在我过去的文章《CSO的生存艺术》http://bbs.chinaunix.net/forum.php?mod=viewthread&tid=1163970 中提到一些因势利导的方法,现在回头看这些方法固然值得一用,但也不是最先应该拿出来的。很多时候我认为甲方安全团队思路受限的地方在于:总是把安全放在研发和运维的对立面上,认为天生就是有冲突的。不信回顾一下开会时是不是经常有人对着研发和运维说“你们应该如何如何……应该这么做否则就会被黑……”诸如此类的都反映出意识形态中安全觉得研发就是脑残,运维就是傻叉。为什么我之前用了“合作”一词,其实换个角度,你真的了解开发和运维吗,是不是找到个漏洞就心理高高在上了?你是在帮助他们解决问题,还是在指使他们听你行事,如果你是产品研发的领头人,听到下面的程序员对安全修改怨声载道会怎么想?我的建议是从现在开始不要再用“你们”这个词,而改用“我们”,自此之后便会驱动你换位思考,感同身受,真正成为助力业务的伙伴。其实有些问题处理的好,真正让人感到你提的建议很专业,研发和运维人员不仅会接受,而且会认为自己掌握了更好的编码技能或者安全配置技能而产生正向的驱动力。再通俗一点,如果安全跟研发的人际关系是好的,提什么建议都能接受,如果我认可你这个人,那么我也认可你说的事,反之,本位主义对立,人际关系不好,那不管你提的对不对,老子就是不愿意改,仅仅是迫于CTO的淫威不得不改,但老子心理还是有怨气,老子还是要在代码里留个彩蛋。利用高层的大棒去驱动可能是一种屡试不爽的技巧,但我认为不是上策。

安全策略的推动还依赖于安全建设的有效性,如果大家都看到了安全策略的成效,都认为是有意义的,那么会支持你去进一步推动安全策略的在整个公司的覆盖率和覆盖的维度,反之,如果大家都觉得你只不过是在玩些救火的权宜之计,心理可能会觉得有点low,后续自然也不会很卖力的帮你推,因为没有认同感。所以安全的影响力是不是完全依赖于高层的重视,我觉得有关系,但也跟自己的表现有很大的关系。CTO肯定是要平衡开发运维安全三者的关系的,不会一直倾向性为安全撑腰,而运维和研发的头肯定都是希望有一个强有力的做安全的外援,在别人心中是不是符合需求且值得信赖这个只有自己去评估了。

至于程序员鼓励师,我姑且认为那是一种实施层面的权宜之计,同时反映出安全行业比较缺少既懂技术又情商高那么一点的人。

不同阶段的安全建设重点

救火阶段过去之后会进入正式的安全建设期。第一个阶段是基础的安全建设,这一期主要做生产网络和办公网络的网络安全的基础部分。也就是在“不同规模的的企业安全”章节里大中型企业对应的那些需求(当然也包括中小企业的那些),完成的标志一方面是所提的那些点全都覆盖到了,另一方面是在实践上不落后于公司的整体技术步伐,比如运维侧在用puppet,saltstack之类的工具实现了一定程度的自动化运维,那你的安全措施也不好意思是纯手工的对不对,如果产品团队交付已经在用持续集成了,那你是不是也至少提供个带点自动化的代码检查工具,而不是纯肉眼去Ctrl+F?这一部分其实是很多人眼中甲方安全的全部内容,不过我觉得远不能止于此。如果这个场景切换到准生态级公司,也许要变化一下,直接向全线工具自动化看齐,一开始就同步自研必要的工具。

以上算是解决了安全的温饱问题,第二阶段就是要向更广的方向拓展,一是广义的信息安全,以前是在忙于解决不被黑而抽不出身,现在安全相关的事情都要抓起来,从只对接内部IT,运维和研发部门扩展到全公司,跟安全相关的环节需要加入必要的流程,以前下线的硬盘不消磁的现在要重视起来了,以前雇员可以随意的披露公司的信息以后就不可以了,以前雇员离职的账号不回收的现在开始不可能了,以前DBA可以给数据库插条记录然后去电商上买装备的,那种事从此开始要一刀切断,诸如此类的事情还有很多,其实这个时候你可以把ISO27001拿出来看看了。二是业务安全,比如用户数据的隐私保护,之前安全只是作为保障而不是一种前台可见的竞争力,但现在安全需要封装起来对用户可见,对产品竞争力负责,如果公司已经发展到一个很大的平台,盗号问题都解决不了的,我觉得真的需要考虑一下自己的乌纱帽问题。这一部分对安全圈人士而言可能并不高大上,可能没太多值得拿出来炫技的部分,但是我认为这些是务实的安全负责人需要考虑的问题,这些属于经营管理者视角下的一揽子安全问题,如果这些问题不解决而去发明WAF发明HIDS去,尽管可以拿到安全圈来发两篇文章炫耀一下,但从职责上看属于本末倒置,直接影响公司营收的问题需要先解决。之所以把业务安全放在第二阶段而不是去优化安全基础架构是因为投入产出的边际成本,投在业务安全上,这一部分产出会比较直观,对高层来说安全从第一阶段到第二阶段一直是有明显可见的产出,而如果此时选择去优化基础安全能力,这种产出受边际成本递增的影响,效果会极其不确定,而这时候业务安全问题频发,就会被倒逼至两难的境地,一则优化基础安全的工作做了一半,一则又要考虑是否中途转去做点救火的事情,而安全产出是安全团队对公司高层影响力的所在,只有看到持续的产出才会影响力增加,才会有持续的投入,尤其在老板不是技术出身的公司,他也许很难理解你去发明WAF的价值,他只会问盗号这么严重怎么不解决。这个问题从工程师的视角和管理者的视角得出的结论可能完全不同,安全对高层的影响力是安全团队在公司内发展壮大的基础,这是很多甲方安全团队之痛,你可以对比一下自己所在的环境,安全团队的负责人对大方向的把控上是不是做到了可持续发展,好吧,这个问题有点尖锐。

第三个阶段开源工具不足以支撑业务规模,进入自研时代。其实做攻防和研发安全产品完全是两码事,存在巨大的鸿沟,如果拿做攻防的团队直接去做安全工具开发,恐怕挫折会比较多,即便有些研究员擅长做底层的东西,但对于高并发生产环境的服务器工具而言,还是有很大的门槛的。另一方面做攻防和做研发的思路也截然不同,此时其实是在交付产品而不是在树立安全机制,所以要分拆团队,另外招人。

第四个阶段,安全能力对外开放,成为乙方,不是所有的甲方安全团队都会经历这个阶段,故而此处不展开。不过我想最重要的区别是,经营意识,成本意识,运营,整体交付,2B和2C的区别,线下最后一公里。

从零开始

本篇就谈一下上任之初要做些什么吧,很多没做过甲方安全的人也许都没有头绪,或者你只是接触甲方安全的一个细分领域而不是全貌,也许我说的能为你省点脑汁,因为开始是最难的,等过了这个阶段找到了感觉后面的路就平坦了。

上任之初你需要三张表。第一张表:组织结构图,这些是开展业务的基础,扫视一下组织结构中每一块安全工作的干系人。例如行政、HR、财务部门是跟公司层面信息安全管理的全局性制度的制定和发布相关的部门,内部审计也跟他们强相关;基础架构的运维团队,运维安全相关的要跟他们合作;研发团队,可能在组织结构中分散于各个事业部、各产品线,不一定叫研发,但本质都是产品交付的团队,应用安全和基础服务器软件安全相关的要找他们,也是SDL实施的主要对象;运营、市场、客服类职能他们可能没有直接的系统权限,但是会有一些诸如CMS的后台权限(被社工的对象),广告的引入发布(挂马的iframe,黑链)等乱七八糟的安全问题的关联者,他们也是某些重大安全事件上升到社会影响的危机管理的公关部门;(大)数据部门,因为安全也要用到大数据,看是复用一套技术架构还是自己搞,这个取决于每个公司的实际状况,有的自己搞,有的则复用;产品部门,一些跟业务安全和风控相关的安全建设要跟他们合作;CXOs这里泛指组织中的决策层,什么问题要借助他们自己拿捏吧,双刃剑。

第二张表:每一个线上产品(服务)和交付团队(包括其主要负责人)的映射。这张图实际就是缩水版的问题响应流程,是日常安全问题的窗口,漏洞管理流程主要通过这些渠道去push,一个安全team的leader通常需要对应一个或若干产品的安全改进。不过这里也要分一下权重,比如支撑公司主要营收的产品需要一个主力小团队去负责其SDL全过程,而边缘性的产品一个小团队可以并发承接好几个甚至10个以上的产品,粒度相对粗一点过滤主要的安全问题即可,通常这样做符合风险管理方法论,但对于深知大公司病又创业过的我来说,还是稍微有些补充的看法,很多成长中的业务,出于起步阶段,没有庞大的用户群,可能得不到公共职能的有力扶持,例如运维、安全等,明日之星的业务完全可能被扼杀在摇篮里,这种时候对有责任心的安全团队来说如何带着VC的眼光选择性的投入是一件很有意思的事。在一个公司里是安全团队的话语权大还是支柱产品线的话语权大?当然是支柱产品,等产品成长起来了再去补安全的课这种事后诸葛亮的事情谁都会做,说的难听一点业务成长起来时自己都能去建安全团队了,不一定再需要公共安全团队的支持。锦上添花还是雪中送炭业务团队的这种感受最后也会反馈给安全团队,so, up 2 u!

第三张表:准确的说应该是第三类,包括全网拓扑,各系统的逻辑架构图,物理部署图,各系统间的调用关系,服务治理结构,数据流关系等,这些图未必一开始就有现成的,促成业务团队交付或者自己去调研都可以,以后的日常工作都需要这些基础材料。如果运维有资产管理也需要关注一下。

到了这里你是不是跃跃欲试,想马上建立完整的安全体系了?估计有人恨不得拿上扫描器去扫一遍了,别急,就像那儿童歌曲唱的“葡萄成熟还早得很呐!”,你现在的角色还是救火队长,离建设还早,这跟你的能力和视野没关系,这是客观情况决定的,一个安全没有大问题的公司通常也不会去找一个安全负责人。找安全负责人的公司意味着都有一堆安全问题亟待处理。这里就引申出一个问题,一般情况下都是出了比较严重的安全问题才去招聘安全负责人和建立专职的安全团队的,就是说这些系统曾经被渗透过,或现在正在被控制中,没有人可以确定哪些是干净的,哪些是有问题的,而你加入的时间点往往就是安全一片空白还不确定是不是正在被人搞,有人说系统全部重装,那你不如直接跟老板说全部系统下线,域名注销,关门算了,那样子显然是行不通的,所以防御者不是时时处处都占上风。这个问题只能灰度处理,逐步建立入侵检测手段,尝试发现异常行为,然后以类似灰度滚动升级的方式去做一轮线上系统的后门排查。

一开始的安全不能全线铺开,而是要集中做好3件事,第一是事前的安全基线,不可能永远做事后的救火队长,所以一定要从源头尽可能保证你到位后新上线的系统是安全的;第二件是建立事中的监控的能力,各种多维度的入侵检测,做到有针对性的、及时的救火;第三件是做好事后的应急响应能力,让应急的时间成本更短,溯源和根因分析的能力更强。

一边熟悉业务,一边当救火队长,一边筹建团队基本就是上任后的主要工作了。如果团队筹建的快,这段阶段2-3个月就可以结束了。

建立一支安全团队

注: 这个题目有一个上下文,就是在我写的企业安全系列里,只针对去互联网公司建立甲方安全团队,不适用于其他场景

如果要去一家公司领衔安全建设,第一个问题就是如何建立安全团队。上面提到不同的公司状况对应的安全建设需求是不一样的,需要的安全团队也是不一样的,所以我按不同的场景来深入这个问题。

在目前国内的市场中,BAT这种公司基本是不需要你去组团队的,对安全负责人有需求的公司大约是从准生态级互联网公司、平台级互联网公司、大型集团的互联网+、千千万万的互联网创业型公司……

如果你在一个小型极客型团队,Youtube被Google收购前只有17个人,在这样的公司你自己就是安全团队,俗称“one man army”,此时一切title皆浮云,需要的只是一个全栈工程师。

对于绝大多数创业型公司而言,就像之前所说的,CSO不一定需要,你拉两个小伙伴一起去干活就行了,今天BAT的安全总监们,当年也都是手把手干活的工程师小伙伴,10多年过去了,工程师熬成了“CSO”大叔。当你的公司变成BAT时,只要你成长的够快,也许下一个就是你自己。

安全的人现在其实很难招,很多企业都找不到安全负责人,所以会有一堆没有甲方安全实操经验或者没有整体安全经验的人被推上安全Team Leader的岗位,对绝大多数公司而言,安全建设的需求都是聚焦于应用的,所以安全团队必然也是需要偏网络和应用的人,大牛显然是没必要的,而懂渗透,有一定网络系统应用攻防理论基础的人是最具培养价值的,除此之外乙方的咨询顾问、搞安全标准的、售前售后等在这个场景下的培养成本都很高,不具有短期ROI所以都不会是潜在的候选者。在安全技术领域里,其实只有两类人会有长期发展潜力:一类酷爱攻防的人,对绕过与阻断有着天生的兴趣,第二类就是可能不是很热爱安全,但是CS基础极好的程序员,这一类放哪里都是牛人,第一类则跟行业相关。粗俗一点的说法找几个小黑客或者委婉的说法找几个会渗透的白帽子就能去做企业安全了?这种观点是不是有人会觉得偏科的厉害了。确实我也认为会渗透跟做企业安全的系统性建设之间还是有比较大的鸿沟的,仅仅是说在有限选择的情况下,假如你不像某些土豪公司一样随便就能招成手,那么可选的替代方案中最具可行性和性价比的是什么,之所以选会渗透懂攻防那是因为具备了在实践层面而不是理论层面真正理解安全工作的基础,在此基础上去培养是非常快的,策略、流程、标准、方法论可以慢慢学,因为这些都不是救火时最需要的技能,而是在和平年代且规模较大的公司才需要的东西。看有些公司的招聘工程师的要求里还写着要证书什么的,不禁感慨一下,很多能做事的“骚年”其实根本没有证书,有证书的人通常适合去做乙方的售前而不是甲方的安全工程师,甲方招聘要求证书的,基本上都是传统行业,互联网行业里这么写的*通常情况下*你也许应该怀疑一下那里的整体水平。当然了这个说法对安全负责人的招聘不成立,因为国内的CTO很少有懂安全的,招聘者其实也不知道安全总监到底需要哪些技能,随便COPY了一个也很正常,高端职位的JD很多时候都是模糊的,除了一个Title之外其他都要聊了才知道,这时候你就不要去嫌弃JD怎么写的这么差,毕竟老板也不懂这事该怎么做,找你就是为了解决这个问题。

单纯攻防型的人在前期培养比较快,但当安全团队随着公司规模和业务快速成长时,思维过于单点的人可能会出现“瓶颈”,后面会提到安全建设实际上是分阶段的,而且是系统性的,视野和思路开阔的人会从工程师中拔尖出来,成为安全Team中的Leader。

对于比较大型的平台级公司而言,安全团队会有些规模,不只是需要工程师,还需要有经验的Leader,必须要有在运维安全,pc端web应用安全以及移动端app安全能独当一面的人,如果业务安全尚无归属或空白地带的话,还需要筹建业务安全团队。

准生态级公司建安全团队这种需求比较少,但因为自己曾被问及这样的问题,所以就把思考的结果写出来。对于这种级别的公司,由于其业务线比较长,研发团队规模通常也比较庞大,整个基础架构也构建于类似云计算的底层架构之上(姑且称之为私有云吧),光有应用安全的人是不够的,安全的领头人必须自己对企业安全理解够深,Leader这一级必须对系统性的方法论有足够的了解,随便举些例子,(1)在出安全事件时如果leader的第一反应是直接让人上机器去查后门的,(2)对运维系统变更风险不了解的,(3)对在哪一层做防御性价比最高不熟悉的,(4)不明白救火和治病的区别的(这种思路会一度体现在提的安全整改建议上),诸如此类的状态去担任leader就会比较吃力(Leader上面的安全老大自然也会很吃力)。另外Leader的跨组织沟通能力应该比较高,在这种规模的公司,不是你的安全策略提的正确就一定会被人接受的。团队里还应该有1-2个大牛级人物,所以带队人自己应该是在圈内有影响力的人,否则这些事情实践起来都很难。

实际上当你进入一个平台级公司开始,安全建设早已不是一项纯技术的工作,而技术管理上的系统性思路会影响整个安全团队的投产比。

创业型公司一定需要CSO吗?

 

转一个我在知乎上的帖子:http://www.zhihu.com/question/27560328

其中的abc轮并不代表企业发展的某种阶段,只是一个象征性描述,写于2015/1/13

最近听说不少创业型公司都在找CSO,也有找到我的,就分享一下我对这个问题的思考。首先这个问题即便是对同一个人而言可能答案也会因时而变(例如我),其次CSO只是一个代表性的称呼,大家不要过于纠结一定要做什么事才算CSO,CSO和CISO又有什么区别之类的,在这个语境下用来指代招聘方想找一个拥有全局安全管理经验的,经验丰富的甚至最好是资深的从业者并且能带一支哪怕是几个人的安全团队,事无巨细能把安全相关的事全部揽过去这样的人。

对于尚在天使融资阶段,找个CSO大多就是去忽悠投资人的,通俗一点理解就是凑一支履历光鲜的队伍去“骗钱”,能不能做事情这个很难说,也不能说人家一定做不了事情,这种只能事后诸葛亮盖棺定论,随便说人不靠谱也是不负责任的,不过我想对于大多数有不错岗岗位的人而言应该是不会去的。

第二种,拿到A轮,业务方向已被证明,业务量不大但进入快速成长期,问题层出不穷,CEO和CTO觉得头疼并且想把这部分压力转嫁出去,理论上是应该找一个懂安全的人的,但是现在这个时间点也就是2015年真的不是一个好时间,在当下很多公司100-200w也经常找不到合适的CSO,创业型公司要在这个层面上争夺安全人才真的是很累的一件事,取而代之应该找2-3个靠谱的安全工程师,然后CTO(技术总监),运维Leader,开发的架构师这几个角色自己遇事应急性补一点安全的知识和方法论,哪怕是充当救火队长赶鸭子上架的方式大家配合一下,累一点应该也能把安全撑起来,不一定非要找一个大牛级的CSO,因为有时候业务量没那么大规模,不一定需要很高level的人,且创业型公司为了保持自己的鲜活也不需要套用大公司的流程和方法,做好基础的运维安全,代码安全,加强一些安全意识,不出问题的时候腾出时间来研究一下下一步怎么做,跟时间和业务增长速度赛跑,跑着跑着,应该就会越来越轻松。当然了,作为创业者,如果你有一个安全领域的朋友愿意帮你出谋划策,偶尔回答一下安全建设如何做这类问题,其实那CSO的需求也就解决了,代价只是请吃几顿饭?呵呵

第三种拿到B轮,业务初具规模,开始朝更高的地方冲刺,同时能给人画更多的“饼”,如果之前已经招到靠谱的安全工程师,那这个时候应该已经成长起来,承担起leader的角色,通常也不需要从外部招CSO了,这个时候想从外部招CSO的都是之前主观的或被迫的不太重视安全,被捅菊花了才想要头痛医头脚痛医脚,这个时候的业务形态跟大公司比应该是“麻雀虽小五脏俱全”,安全管理上应该是有很多相似的地方了,对于出具规模的业务而言安全管理的经验很重要,可以直接从大公司挖人,当然了level较高的估计还是挖不动的,主要就是骨干那一层的人吧,通常你需要容忍他们业务上有深度但不一定面面俱到,很可能情商和管理能力也差强人意,不过能解决你的问题就行,面面俱到的毕竟还是太贵了,呵呵

第四种拿到C轮冲IPO,这个时候想必不会囊中羞涩,如果看官你是这个区间公司的CXO,还为找不到人感慨万千,我想也许是心态还不够开放,亦或许是给人的“诚意”还不够,到这里我也给不了太多建议了,毕竟市场上只有那么一小撮人,来不来去不去也就是那一小撮人的意愿而已,被打动了自然来,没被打动的自然不去~

创业公司的那些事对选择转会的CSO是否有挑战?有,也没有。首先做的事情往往还是从头建团队,把过去建设安全体系的过程从零开始再做一遍从这个角度讲重复过去做的事情尽管业务有所不同但过程和结果上未必有挑战,有“挑战”的反而是如何在创业公司的条件下招募成员,维系团队和在很多流程及界限不分明的情况下推动事情落地,仅此而已,对CSO本人而言得到的实践机会未必有大公司多而广,因为安全是一个随规模而复杂化的工作。但是,如果你是CSO的跟班小弟,那你可能是成长最快得到锻炼最多的人,因为你经历了安全建设飞速发展从无到有,从简单到自动化的过程,这个过程不是人人都能体验,所谓的全局视野并不是你进入BAT在一个很细的分支上耕耘几年就能积累到的,相反是在这种环境下才能快速积累。所以除非公司IPO,CSO都不是团队里收益最大的人,但跟班小弟却是最大的赢家,哈哈

甲方的同学看了是不是觉得有很多场景很相似,是不是该珍惜当下,因为有些令你痛苦的事情,恰恰就是你成长的机会,区别只在于你选择了什么方法解决这类问题,你的解决问题的方法拿到业界算得上是最佳实践么

安全建设需求:生态级公司vs平台级公司

事实上并不存在我说的这种分类,即生态级公司和平台级公司之间没有必然需要这么做,必然需要那么做的条条框框,但是两者的安全建设需求之间确实不仅仅是量的差别而是质的差别。

         主要差别表现在是否大量的进入自己发明轮子的时代,即安全建设需要依托于自研,而非采用商业解决方案或依赖于开源工具的实现。上一篇提到金融行业的高成本安全整体方案几乎全都依赖于商业方案,这是跟大型互联网安全建设有很大的区别,假设金融行业的CSO去互联网公司可能会比较吃力,反之在适应金融行业的BCM后则能轻松驾驭,这个观点因为有明显的倾向性,所以肯定是会受到挑战的,不过我写这些的本意也并不是为了讨好所有人,时代的浪潮总归是有所指,不会所有的人都是受益者。

         那么平台级公司和生态级公司的区别又在哪里,从表象上看,生态级公司的大型基础架构如果用传统的安全方案几乎都无法满足,所以会大量的进入自研,而平台级公司则会依赖开源工具更多一些,不会全线安全工具进人自研。如果有预算的话也会优先投在“业务安全”侧,比如反欺诈平台等等,而不会自己去搞入侵检测,当然这有可能是个伪命题,有可能当我的企业安全系列全篇写完时,乙方公司也开始提供具有可扩展性,能应对分布式架构的方案,或者当时间尺度拉的长一点,平台级公司每年在自研上投入一点点,多年之后也具备了BAT级别的安全能力也并非完全不可能,不过这些都是理想状况,现实总是受到多方面因素制约的。

         首先影响的第一因素是技术驱动的层次,在底层还是在应用层驱动业务。表象上平台级公司和生态级公司都是以pcweb服务为入口的平台应用和以移动端APP入口的移动应用,有的依赖于一些PC客户端或移动端偏底层的APP,但在技术实现方式上,平台级公司更多的直接使用或少量修改开源软件,而生态级公司的IT基础设施则会类似于Google的三篇论文一样,不仅仅停留在使用和少量修改,而是会进入自己造轮子的阶段,其中所造的轮子是否对业界有意义这种问题暂时不去评价,但对应的安全建设则反映出平台级公司的安全主要围绕应用层面,而生态级公司的安全会覆盖基础架构和应用层面两块。直接使用开源工具的部分交给社区去处理,自己跟进打补丁就行了,但如果是自己开发的,那么就需要自己去解决一揽子的安全问题,比如Google造了Android这个轮子,那Android一系列的安全问题Google需要自己解决,比如阿里自己去搞了一个ODPS,那阿里的牛人也需要解决这个,再比如我所在公司在物联网领域造了LiteOS这个轮子,自然也要去处理对应的问题,而这些偏底层的问题显然早已超出应用安全的范畴,也不是一般的甲方安全团队有能力应对的。其实有些平台级公司也是发明了一些轮子的,比如自动化运维工具,比如一些NOSQL,不过IDC规模两者之间仍然差的比较远,上层的业务复杂度也有差距,支持的研发团队的规模也有差距,对安全工具的自动化能力和数据处理规模仍然存在阶梯级的差别,这一点也决定了为什么要自研。安全其实只是IT整体技术建设的一个子集,当整体技术架构和实现方式进入自产自销阶段时,安全建设也必然进入这个范畴。对于很多实际上依靠业务和线下资源驱动而非技术驱动的互联网公司而言,安全建设去做太多高大上的事情显然是没有必要的。

第二因素是钱,钱也分为两个方面(1)成本(2ROI。假设安全投入按IT总投入的固定10%算,又假设生态级公司的安全建设成本是平台级公司的5-10倍,这个成本除了带宽、IDC服务器软硬件,还有技术团队,加起来才是总拥有成本TCO10个人的安全团队和100个人的安全团队能做的事情相差太大,具体可以参考我在知乎上的帖子《为什么从事信息安全行业一定要去大公司?》http://www.zhihu.com/question/27356955。还有一方面则类似于“去IOE”,上面提到目前对于大型互联网没有合适的安全解决方案,即使有,这个成本可能也会无法接受,所以假如乙方公司能推出既能支撑业务规模,又具有性价比的方案的话,我认为甲方安全团队真的没有必要再去造轮子了。

         第三个因素是人,安全团队的人员数量也只是一个很表面的数字,安全团队的构成才是真实反映,能囤到大牛的安全团队和由初级工程师组成的安全团队显然是不一样的,一方面前者的成本不是所有的公司都能接受,其次,平台不够大即使大牛来了也未必有用武之地。大多数平台级公司的安全团队其知识和经验集中在web/app,应用层协议,web容器,中间件和数据库,生态级公司则扩展至系统底层,二进制,运行时环境和kernel级别,能力积累也存在差别。这里并无褒贬之意,仅在说明业务对技术的需求不一样。

         那平台级公司是不是就没有乐趣呢,其实他们也玩一些小花样,比如修改sshdLVS,加入一些安全特性。可能也会自己定制一个WAF,或者搞搞日志的大数据分析。但比如涉及DPI,全流量入侵检测,SDNkernel level的安全机制基本上都不会介入。这些对一个规模不是特别大的平台级公司的甲方安全团队而言门槛还是有点高。

         自己发明轮子是不是全领域进军呢?也不是,主要还是在入侵检测、WAF、扫描器、anti-DDOS、日志分析等领域。在SDL环节上可能也会自己研发些工具,但未必有直接使用商业工具来的短平快。阿里钱盾、腾讯管家、百度杀毒这些都跟360客户端一样跟生产网络没什么关系,就不去讲了。另外自研有一个原则:都限定在民用领域,不会自己去发明一个RSA算法这样的东西。

国内的平台级公司里也有一个例外数字公司,因为其主营业务是安全,所以就不会受到安全投资固定占比理论的影响。