浅谈安全方案的建设周期

 

隔三差五总能看到各种大牛大神的NB技术文章,诸多新颖新奇的方案。另一方面,旁观者(有时甚至是团队内部同学)总感觉一个安全问题很久得不到解,或者一个方案长期不能落地。鄙人算是完整的经历了多个安全项目、安全系统的建设周期,这里为大家分享安全技术方案的整个建设周期是怎样的?本文不想冗长的讲大项目和系统,那些周期过长影响项目进度的非技术因素太多,这里仅讲部分模块和功能的建设周期。

  •      关键环节

咱们不记流水账,不逐个细说。如下图,这是常见的整个方案落地建设关键环节。可能有人就会说了,这个图有问题啊,怎么没有“结项”的时候?是的,我不认为一个安全功能或系统到一定阶段部署之后就不需要管,而是根据攻防效果必须不断跟进迭代。真有所谓‘结项’那天,除非整个功能或系统需要被淘汰了。

1

 接下来说说几个细细唠叨的环节。

  • 评估

需求的来源千奇百怪,也需是某人拍脑袋,也许是看到圈子里有人抛出一个看似NB的方案。在项目启动前必须警惕,作为专业人士的你,肯定是有自己的看法,是否需要做。必要时请说 “NO!”。 在需求已明确的情况下,选择怎样的架构又要考虑到业务方的要求,稳定性、安全性、低能耗等。

  • 预研

不好意思,这里没干货。只是吐槽一下,多数人发出来可能让人眼前一亮的东西(技术方案、论文),仅止步于此。如果没有经历完整的项目周期,经受线上一段时间的攻防检验,对不起,你那只是玩具枪,不是能上战场的真家伙。

  • 开发阶段

开发这里有三部分,“开发”指的是根据业务(安全)需求的架构设计部分;“数据”指的是因需要检测分析某场景所需的数据需;“规则”需求则是指为了满足数据分析模型而产生的开发工作量。

  • 验证

真正的考验开开始,线上环境是否能稳定运行是第一步,接下来需要蓝军渗透测试验证检测能力的有效性,当然最有说服力的是真正的外部攻击是否能实际检测出。前面三个环节任一步出现状况都需要回滚,通常在这些阶段会不断的踩坑,并且是周期最长的阶段。项目进入这个阶段蹦掉的也不在少数,请坚持下去。

  • 迭代与重构

为什么多出来一个阶段?攻击方会不断的变换各种姿势希望绕过你的检测,那么迭代是必不可少的,你不希望刚建设完毕的系统面对攻击就无效了吧?那些无迭代能力,无持续运营的系统必然被淘汰。

  •      时间周期

2

以一个段子开始这节。鄙人近十年经历了3个互联网公司(三年久游、五年鹅厂、一年阿里)的诸多安全项目,通常整个入侵检测体系,从系统开发到最终全面上线稳定有效运营,再快也是三四年起。投入的人力,架构、开发、部署、运营、规则开发等也都是至少7-8人的专职投入,还不算周边的产品、项目等同学。说到这里,不知诸位看官是否get到了笑点?

回归正题,下面是去年经历的一个安全模块的项目周期,完整记录了从“需求产生”到可用“接入SOC”的耗时。不一定每个项目都与此相同,但各阶段的耗时能看出一些特点。 3

  • 需求到demo

你没有看错,从需求产生到有demo出来(未进入实质性开发)仅耗时不到1周。如果项目周期仅以初次上线计算,耗时不到1/5,如果以能全公司全量部署稳定运营时算,则1/10的耗时都占不到。而那些流传在网络上的技术方案和论文,有可能就止步于此了。当然如果你的项目在这里就耗时感觉几乎‘遥遥无期’,那么应该是技术储备不够。

  • 研发阶段

这里基本上是波澜不惊的,场景与需求都清晰,基本上开发同学能应付大多数coding问题。唯一需要注意的是,需要不断跟进验证每个开发交付节点,确保方向没跑偏。可爱的开发同学有时候会根据自己对代码架构的理解去‘优化’,可能结果就是让其在攻防对抗中留下了一个软肋。他们对攻防的理解毕竟不如你清晰,可能前面敲定的某些技术方案、技术点对于最终的效果来说是决定性的。

  • 踩坑迭代

“顺利的项目都是相似的 不幸的项目各有各的不幸”。 当项目走在健康的轨迹上时,不断的发布更新版本,那是在迭代优化。迭代的原因可能是,开发同学发现了一种性能优化的方案;运营同学发现产出的数据有惊人的发现,可以有更多的用途更NB的检测模型,值得进一步深入挖掘。恭喜你,这里可能是您碰到了NB的开发架构同学,或者资深的运营专家。 当项目焦头烂额时,有可能是部署后发现导致线上业务稳定,甚至系统不可用,时长有回滚,好不容易推动的部署量一下子回到解放前。到这里你一定要撑住,这是压力较大的阶段。无论是技术层的代码review、方案的优化,还是应急流程的快速应对,都是搞得人困马乏但必须迎难而上。请善待推动部署的同学吧,他们面对业务方承受了太多压力。

  •      后记

其实写那么多,说白了,请参与建设的同学要有长期作战的准备,各种问题将扑面而来,熬过去了就是胜利。:) 技术研究的同学,实验性方案到落地其实还很遥远,一个demo不踩几次线上系统的坑,没有几次回滚迭代,它永远只是个试验品。 项目运作的同学要有耐心,不要认为一个功能模块的上线以月计,一个系统的成熟完善以年计有什么问题,那是必须的。 管理者的角度来说,请给足时间资源,慢工出细活这真的值。  

预告一下,后面准备整理一个“入侵对抗体系成熟度模型”  。

 

Powershell Hids DEMO

最近有点忙,之前说的 放 “hids demo”   “用Powershell写hids” 等等 ,这次算是顺道一并兑现了,好久不写blog也刷刷  :)。

代码见我的github  https://github.com/xti9er/PowershellHids ,我不是程序员,代码丑见谅。这里也不是为了讲如何写代码,而是体现HIDS或者入侵检测数据分析的思路,这个仅仅是demo,顺道如果大家想用也可以拿去。当然,真正拿去用会有很多坑和问题,大家自己解决吧。

用法 :

  • 添加脚本权限 :Set-ExecutionPolicy Unrestricted
  • 添加日志来源类型:New-EventLog -LogName application -source powershell-hids
  • 运行那段powershell脚本,当有提权事件的时候,会有告警提醒,并写入系统日志(application)。

简单描述一下吧,还记得我早先写过的那些入侵检测策略模型吧?还是老样子,整个逻辑就是 “一个高权限(system)的进程的父进程是低权限则判断为提权”。可能以前写的,懂的人觉得好但不一定能工程化实践;不懂的人可能觉得这人在吹牛B而已。效果见图,这里检测了某个windows漏洞提权,聪明的你应该能想到 这不仅仅只能检测这个 ms15-051而已,理论上这类提权场景都可以检测不管他是0day\1day还是Nday。

Snip20151117_10

网络军备竞赛

2014年12月份的时候在freebuf组织的一个沙龙讲到了,数数据在攻防对抗中的关键性,“

腾讯安全对抗经验分享:数据逐步成为攻防G点#FreeTalk深圳站#

当攻防双方在技术水平上不会有绝对的差距的时候,数据的及时性、全面性就成了决定战局胜负的关键。在大型网络或组织中,这样的场面是非常普遍。

PPT 猛戳这里下载 《网络军备竞赛》

云端博弈——木马屠城

近半年DDOS攻击愈发激烈,而作为攻击的执行者,DDOS木马也是应市场需求也在野蛮生长,笔者就观察到一款被国外安全厂商称之为”XOR DDOS”的木马不断更新代码和功能,甚至还加入了rootkit功能模块。本文将剖析此木马,并给出相应的检测方案。

XOR DDOS木马浅析

此木马因其代码使用xor来隐藏配置信息,被国外某专注于木马分析的网站(mmd-0028-2014-fuzzy-reversing-new-china)称之为‘Linux/XOR.DDoS ’,我们这里也沿用这个叫法。


XOR DDOS代码片段
此木马开发者也算得上是‘劳模’了,近一年的观察发现这个木马代码不断在更新,早先的版本并未有rootkit模块,在2014年下半年发现它已经更新了rootkit模块。


XOR DDOS函数变更趋势

(more…)

web日志取证分析工具

还记得我上一篇Blog《云端博弈——云安全入侵取证及思考》中那个工具吗?通常在调查入侵事件的时候,工具化能最大限度的提升效率,且减少人为主观误判。
此工具可从单一可疑线索作为调查起点,遍历所有可疑url(CGI)和来源IP。

 

使用方法:

 

Perl LogForensics.pl -file logfile -websvr (nginx|httpd) [-ip ip(ip,ip,ip)|-url url(url,url,url)]


File
:日志文件路径

Websvr : 日志类型

Ip: 起始调查IP或ip列表,以逗号分割

url: 起始调查cgi 链接或链接列表,以逗号分割

 

使用效果: