2019安全工程师合格率2019安全工程师考试结果查询
- 安全工程师
- 2024-08-17
- 166
昨天晚上做梦,梦见不知道在之前还是现在的哪家公司,跟同事老板谈hc,说到,当前最大的问题是,人力问题,是人力不够。只有人力解决了,这个team才能运转下去。我就问,那你们团队是做啥的呢?他说做扫描器和漏洞运营。梦里就开始回想在以前公司中,各种方法有效的效率提高和人力节省措施,我就回了一句,人力当然重要,不然事情做不起来,同时在有一定人力的情况下,方法更重要。接着,就开始就扫描器的使用高谈阔论了起来。
啥?扫描器不就一个工具么?有几个人不会用?
这里就讲一讲在甲方互联网公司,扫描器在具体实践中的用法,个人浅见,欢迎交流分享……头次发文,不知道会被喷到多惨……
一、扫描器哪里来?
以前就职的两家公司里,黑盒扫描器都是自研,白盒扫描器只有其中一家有。直到有一次某M公司来做分享,才知道,原来他们的黑白盒扫描器都是靠购买的,乙方提供产品和售后支持。当时纳闷儿,如果是乙方提供,就不怕到时候也不知道代码,添加规则的时候不能满足需求吗?M公司的专家解释,以前M也是自研扫描器,但是发现的问题是,扫描器的开发维护团队的目标,很多时候和具体运营的安全团队是不一致的,更新规则的效率效果也比较不好说;而乙方由于提供给多家服务,样本也更多,产品更专业,提供的服务也更好一些。回想起原来就职的两家公司里,除非扫描器的开发运维和安全工程师就在一个小团队,否则这其中的多个环节也确实很难保证扫描器的快速迭代。
除了比较大的公司,如果是初创公司或者是快速增长期的公司,购买一款质量有保证,售后服务好的扫描器产品都是个不错的选择。当然如果能挖到专业的扫描器大牛过来,进行产品开发,不仅少走很多弯路,还便于内部产品对接,就更好了。
二、扫描器谁来用?
刚入行的时候,发现扫描器定期通过全流量,域名或ip,进行扫描,然后推送到SOC上,安全工程师来进行报警运维,以及后续漏洞的分发。这是对扫描器最早的用户的认识。
随着时间的增长,遇到了一群群特别牛叉的小伙伴儿,见识了,除了常规安全工程师运维,还可以将安全工程师以外的员工动员起来,毕竟,安全不仅仅是一个安全团队的事情,而是一个公司,甚至还有公司外部人员一起来构建的生态。
三、扫描器怎么用? 1. 常规黑盒扫描
收集和维护公司流量,ip和域名信息,对这些资产进行定期全量和增量扫描。
全量扫描,重点在于,要收集和维护公司的资产,并对资产进行有效的去重策略。周期要比增量扫描的周期长一些,这里的重点在于全,而不是快。去重也需要一套完整的策略,不过此处不作过多展开。
增量扫描,对比原有资产库,一旦发现有新增资产,立即进行扫描,这里的重点在于要快。因为如果在历史漏洞能够有效修复的情况下,新增资产出现新漏洞或高危漏洞的可能性更大,需要尽快发现并处理。
2. 黑盒插件扫描
据Net Market Share 的7月份数据,占据全球浏览器排行榜首位的是Chrome浏览器,总市场份额为48.65%。实际工作中,也确实不少的程序员喜欢用Chrome浏览器。甚至于,不少浏览器直接使用的是Chrome的内核。
在这个前提下,开发Chrome浏览器扫描插件成为了可能。
由于黑盒扫描基于URL即可扫描发现漏洞的特性,只要通过Chrome或其内核浏览器浏览过的URL,都可以通过插件进行收集抓取,并进一步进行黑盒扫描。只要安全工程师将插件开发成功,并推广到公司的开发和测试安装使用,那么开发和测试在线下环境中就可以自行检测出漏洞,只要安全工程师准备好相应漏洞的修复方案,开发即可自行修复上线。无需等待产品上线,将安全风险暴露到外面后,外部或安全工程师再倒推给开发修复。不仅是降低了安全风险,也节省了安全工程师的工作成本。
3. 黑盒自助扫描
仍基于拿到URL即可扫描或爬取漏洞的特性,可以将扫描器后台功能,开发成前台产品,供对漏洞了解并未达到专业程度的开发或测试使用。
产品形态可以就是简单的输入框,用户输入URL,点击扫描,即可对该URL进行黑盒漏洞扫描。
对于更深度的用户,也研发定期,批量,爬虫或接口扫描等功能……可以做的事情就很丰富了。
4.服务器扫描
这个原理是,抓取开发或测试的服务器上的日志,推到扫描器,进行定期自动化扫描。好处是一旦配置了,就能准确的收集到最新变动的代码的日志,并且中途无须人工进行更多的操作,只需等待结果即可。
需要注意的是,要尽量开发封装的agent,而不仅仅是接口,因为封装的agent在开发或者测试接入的时候成本更低,推广起来也更容易。如果公司内webserver类型不统一,那么可能需要开发Apache,Ngnix,lighttpd等多个适用版本来进行接入。
5. 白盒代码扫描
白盒的代码扫描,理论上也可以运用方法3中,输入代码路径的方式进行自主扫描。还有一种方案就是,将白盒代码扫描,封装成一个脚本或者包,推广给开发,在开发常规开发的时候,跑一遍脚本或者包,显示哪里的代码可能会产生安全漏洞。
这个方案的难点有两点。一是,如果公司开发使用的是多种语言,那么包的适配和开发上可能就需要花比较多的心思。二是,白盒扫描本身产生的误报,想做好控制也比较难,这就要在漏报和误报间做好权衡,至少选择添加误报达到某一基准线的规则,并做好引导说明,否则容易败RP。
6. 上线平台扫描
如果是比较专业的公司,代码上线,一般都会有上线的平台或者系统做支撑。
如果在上线前接入黑盒白盒扫描,并对漏洞进行修复,更是事半功倍。
需要注意的几个事情是:
第一,要和上线的平台打通,取得相应平台,以及平台的用户的支持,这部分建议还是先走试点然后逐步推开。
第二,接入黑白盒扫描,不要等到最终上线那一刻再去扫描,而是尽量将扫描的步骤提前,进行预扫描,加快速度,提高用户体验。
第三,对于扫描的结果,哪些可以不修复就上线,哪些必须修复后上线,必须制定相应的策略,明确不修复上线的风险确认方式。
第四,对于扫描器扫描规则的维护,需要在安全自己的系统中,而不是上线的平台。这样添加规则,设置白名单,能够不受上线平台的影响,自己掌握主动权。
最后,任何一种扫描器都不能解决所有的问题,有必要的情况下,对于重点业务可以通过设定策略,添加人工测试。
四、扫描器怎么维护?
衡量扫描器好坏最简单的就是漏报和误报率,如何尽量降低漏报和误报,是扫描器安全上的最主要目标。当然,稳定性,效率,速度不可忽视,不过此处不做详细说明。
1.漏报
漏报是难免的,重要的是每次发现漏报后能够更好的处理和解决,并且和误报做好平衡取舍。漏洞一旦通过各种非扫描器的渠道上报后,要有专门的人对该漏洞进行分析和规则添加。这其中,疑似漏报的漏洞的通知规则和方式,根据漏洞类型进行初步的过滤和筛选,以及后续的规则添加都可以进行策略制定,这些都可以提高工作的效率。
此外,对于基础资产,包括但不限于流量,域名,ip,代码路径相关信息,进行收集和维护,也是减少漏报的重要途径。不过,大公司资产分布较多,初创公司基础建设又有可能不完整,收集资产都是个不易的任务。根据过往有限的经验,如果安全团队有人力的话,最有质量的方案,是将资产梳理和资产数据,通过各种方式,汇总到自己的平台上,自己进行维护。如果依赖其他平台运维,后续无论是工作对接上,还是保证数据准确性上,都会有无穷无尽的麻烦。梳理资产确实是个比较需要耐心,恒心,毅力和沟通能力的工作。
2.误报
这里涉及到的是添加规则。如果是自研扫描器,非常非常建议,添加规则是通过动态配置,而非更新代码。因为规则本身就是不断变化的,如果每次规则变化都依赖开发,后续的麻烦,你懂的。
最后,安全不是一个团队的事情,而是联合公司内外各种力量建立起来的生态。
任何一种扫描器也无法扫描出全部的漏洞。
向奋斗在第一线的安全从业人员致敬。
文章来源:FreeBuf
作者:安惞
免责声明: 本站提供的任何内容版权均属于相关版权人和权利人,如有侵犯你的版权。 请来信指出,我们将于第一时间删除! 所有资源均由免费公共网络整理而来,仅供学习和研究使用。请勿公开发表或 用于商业用途和盈利用途。
本文链接:http://erjian.cc/anquan/25837.html
发表评论