随着攻击向量扩大和漏洞增加,漏洞管理成为安全解决方案的最前沿,成为风险管理的重要组成。安全团队面临两难:安全漏洞数量激增、无处不在,安全预算却在减少和安全人才持续短缺,修补每年发现的惊人安全漏洞简直遥不可及的任务,简单的发现和修复模式已经难以为继。
安全漏洞一直被视作攻击企业的入口,以各种形式存在于企业信息资产的方方面面,稍有不慎,安全防线就可能被击破。
通过从组建漏洞管理团队、在现有大流程中设计漏洞管理流程、增加漏洞发现方法、建立漏洞管理闭环流程、形成漏洞复盘机制、构建漏洞评价体系、推动漏洞发现转向漏洞预防等7个方面,对企业的安全漏洞进行全面、深度的治理。
漏洞涉及的范围广泛,故管理难度也非常大。通过建立专项工作组、部门BP 制度、安全团队内部分工等式,为漏洞管理提供最有力的支撑。
专项工作组:无论是建立虚拟或实体的工作组,都应该自上而下,需要包括产品、开发、测试、运维、安全等不同角色的人员。各企业中相关岗位可能已经有一定的组织,那么在建设专项工作组时优先考虑将其纳入或联系其主要成员加入,如下图所示的研发委员会、安全委员会等。明确该岗位的工作目标与工作职责,比如,研发需要对自己所写程序的安全质量负责,主动学习安全人员提供的开发安全规范、进行开发安全考试、在编码时安装安全IDE 插件进行安全检查、编码完成后触发静态代码安全扫描工具进行安全检测、针对安全检测结果联动安全人员进行漏洞确认与修复、在运营阶段若是发现产品编码相关漏洞需要及时响应与修复。
· 部门BP制度:建立部门的安全接口人,负责对接安全人员上传和下达消息、在本部门落地相关安全要求。建立的机制依旧是从上往下,通过专项工作组发通知给各部门的负责人,由负责人亲自指定并声明该部分工作的重要性,争取对接口人有一定的考核权,让安全工作正式成为接口人职责的一部分。前期可对接口人的配合情况和工作质量进行排名、正向反馈,最终需要落实到绩效考核上。安全接口人需要对部门内部的产品、研发、测试人员进行联动、驱动,承接部门漏洞的管理职责。
为了保证各项安全活动有效落地,安全团队内部可根据安全活动不同的方向设置团队,包括安全防护、安全运营和产品安全团队,内部的漏洞管理工作也主要是由这三个团队负责。
· 在安全防护团队中,设置专岗人员进行资产信息收集与识别、最新漏洞跟进分析、编写POC、执行漏洞扫描等工作;
· 在产品安全团队中,负责产品上线前的安全测试及SRC 运营,通过引入白盒测试、黑盒测试和灰盒测试等方法发现并推动漏洞修复。
漏洞频现,发现的方式也比较多。但如何才能持久、高效、有效地发现并管理漏洞呢?在经过长期实践之后,总结出以下两点漏洞管理方式,最核心的思想就是“嵌入现有的一切流程”中。
为进一步提升产品与信息系统的自身安全能力,防止产品与信息系统带严重、高危和中危漏洞上线,有效减小集团信息安全事件发生的概率。在产品发布节点上设置了安全卡点,未经过安全提测或安全提测结果不达标的产线,将被禁止发布上线。同时由于安全人员有限,将部分安全测试能力融入到产品中,交由产线来完成,以此保障该措施能够落地。基于开发流程的安全测试流程,如下:
最开始的节点始于产线,在完成自主安全测试并漏洞修复后,可进行安全提测;产线提交安全提测工单后,进入排队待测试状态;安全测试人员分配到安全提测工单后,进入测试中状态;安全测试完成后,由产线进行漏洞修复,提测工单状态为修复中;漏洞修复完毕并经过安全测试人员验证,提测工单状态为安全测试通过。
无论是漏洞的发现,亦或是漏洞的修复,均需要明确存在漏洞的资产归属情况,故资产管理是漏洞管理的另一个基础。基于资产(操作系统/应用/组件)进行漏洞扫描,可以提升扫描效率、降低网络流量;基于资产(重要级别/网络位置)进行漏洞修复判断,可以提高必修的漏洞修复率;基于资产(使用人/运维负责人/安全负责人)进行漏洞修复推动,可以提高整体的漏洞修复率。以下为漏洞运营平台结构图,清晰的展示了与资产管理的紧密联系。
通过从安全媒介、软件官网、国内外漏洞平台、社交软件等途径,实时获取漏洞情报信息、漏洞利用信息等,结合公司的信息资产对内进行预警。对于银行、证券、运营商等行业,还会收到来自上级监管单位的漏洞预警通知。常见的漏洞监测情报包括CNVD、CNNVD、CVE Details、CVE等漏洞平台;可以是Freebuf、安全脉搏等安全媒体;还可以是微信朋友圈、推特等社交软件。
对漏洞情报的处理,是接收到漏洞情报后应立即开展的工作,也是对安全人员对自身资产熟悉情况、对新漏洞理解的考验。通常若漏洞有CVSS评分,则可以直接关注7.0分及以上的漏洞,进一步还需要结合以下几个维度进行综合评估。
定期使用扫描器对资产进行主机漏洞和Web漏洞扫描,是较为常见发现线上系统安全漏洞的方式之一。扫描频率和扫描规则决定漏洞的发现能力,扫描频率原则上在能覆盖所有资产的基础上越频繁越好,扫描规则需要根据漏洞情报或厂商及时更新。在常见的漏洞工具中,无论是系统还是Web层面,一般都支持登录扫描,但以此带来影响业务的风险也随之增大,特别是实时性要求很高的业务系统对扫描比较敏感,所以在进行扫描前需要注意以下事项。
· 扫描器地址加白:扫描器的地址加白包含两层意思,一是在一些特殊的网段或业务系统放行扫描请求,实现覆盖率全局覆盖;另一方面是在安全防护设备上添加白名单,防止被安全设备拦截导致扫描无果,同时也减少扫描时产生的大量告警,避免给安全运营带来巨大的工作量、已知的扫描告警淹没掉有真正攻击的有价值的告警。
· 设置扫描时间窗口:从扫描类型(系统/Web漏洞)和扫描目标(内网/外网系统)进行区分,设置每天扫描开始和结束的时间,每月/每季度的扫描频率,在制定的时间内进行扫描工作。
· 扫描前通知业务方:将制定的扫描任务与计划在开始前,同步到业务方并获得其统一,可以提高扫描时出现线上故障的处置效率。另外有一些业务系统也会反馈不能扫描,需要添加扫描的白名单。
· 留意加白业务系统:针对扫描加白的业务系统,可以通过进一步确定扫描作业开始时间、加大扫描周期、扫描一比一的测试/预发环境、根据系统架构等基础信息进行精细化扫描等多种方式来发现漏洞,防止因为加白而导致的扫描盲点。
· 多款扫描器交叉扫描:不同扫描器的规则(能力)不一致,对漏洞的检出能力也有所差异。从黑客攻击、上级单位扫描检查等角度出发,需要将常见的扫描器加入到扫描武器库中,实现漏洞在被人发现之前先发现,掌握一定主动权。
· 对扫描器的操作进行审计:由于在网络和防护层面都对扫描器开放,扫描器上已知漏洞也属于公司的重要资产信息,需要对扫描器的登录、登出、扫描任务制定等关键操作进行审计,做到事后可取证追溯。
业务上线前进行安全测试,基本已经成为拥有安全人员的企业必做安全工作之一,也是漏洞发现的主要来源。通过建立安全提测流程,设置业务上线卡点和安全质量要求,促使业务上线前都来进行安全测试并进行漏洞修复。
· 黑盒主动漏扫:这应该是最常见的发现漏洞方式,也常常作为安全测试中的安全基线,使用工具通过爬虫获取待检测系统的API,加载各类payload进行漏洞扫描,包括主机漏洞扫描和Web漏洞扫描。主机漏洞扫描器基本都是商用的,比如Nessus、绿盟RSAS等;Web漏洞主动式扫描工具种类较多,包括耳熟能详的AWVS、w3af、Nikto、OWASP_ZAP等,大多都可通过开源方式获得。黑盒主动漏扫能发现常见的漏洞,但是在覆盖面方面存在一定的不足,就Web漏扫而言,针对单个链接的孤岛因为爬虫找不到路径、使用防重放一次失效token的页面等,通常会检测不到。
· 黑盒被动漏扫:相对于主动方式的漏洞扫描而言,被动漏扫最大的区别就是获取的URL来源不同,一般包括通过流量提取和日志解析。在功能测试时或者线上环境产生的流量中,提取待测系统的URL、去重、加载payload、重放进行安全测试,从而覆盖到用户能接触到的所有系统功能。至于工具方面,以商业和大型互联网公司自研两种形态为主;另外也出现一些社区版的产品,比如xray;半自动化的工具Burpsuite + 自研漏洞插件进行漏洞扫描。
· 白盒安全测试:在安全测试领域,静态代码扫描通常作为安全测试在开发安全生命周期中左移一步的重要标识。通过对代码进行安全扫描,可丰富被发现的安全漏洞的种类,比如除了常见的SQL注入、XSS、CSRF等OWASP Top10类型外,还能检出硬编码密码、不安全的随机数、日志伪造、路径操纵等类型的漏洞。
· 手工安全测试:无论是黑盒还是白盒安全测试,工具发现的漏洞总是有限的,都需要人工的参与。在逻辑漏洞、敏感信息泄露类、有一定防范但可被绕过类漏洞方面,检出率存在短板,往往需要人工根据经验、结合实际的业务场景进行手工分析测试。
· 交互式安全测试:IAST技术将白盒和黑盒安全测试的能力进行融合,能将漏洞定位到代码层面,漏洞检出率高、误报率极低,甚至能做到不产生脏数据(IAST的Passive插桩技术)。在DevSecOps日益推行的今天,IAST必将是安全测试技术的发展方向。
漏洞悬赏最开始流行在国外的HackerOne、Bugcrow等平台,到国内主要以漏洞平台和SRC的形式落地。各大互联网公司也纷纷建立SRC,对外收集自家产品与信息系统以及主流产品的0day漏洞,往往也能收到不少高价值的漏洞。
SRC作为企业安全团队对外宣传、接收漏洞的官方渠道,既能起到沟通桥梁的作用,又可以通过接收到的漏洞反向优化安全防护策略。建设SRC早的企业,各类规则完善、人气高,基本拥有一群稳定的白帽子为其挖洞,白帽子也对业务越来越熟悉,也能发现更多有质量的安全漏洞。对于新建的SRC,则需要通过不断的运营活动来提升行业影响力,吸引更多的白帽子加入。
一是门户的建立,作为一个对外的门户,可以自研也可以通过国内的一些漏洞平台建立企业SRC,漏洞平台的好处是有一定的白帽子基础、运营机制,相比较自研会更加高效快速上线,但也存在定制化功能和效果不佳的弊端。若是自研,可借助开源的程序进行修改,比如SRCMS、腾讯xSRC(开源版)。值得注意的是,如果使用开源方案,则需要持续关注平台本身的漏洞情况,目前已经被发现不少安全漏洞。
二是确定漏洞接收范围,仅限于主域名的子域名,还是包括所有与公司相关的资产漏洞?SRC经常会接收到内部已知管理资产外的资产漏洞,白帽子的能力不容小觑,为避免发生争执需要提前明确。
三是设置有明显区别的漏洞奖励机制,可根据资产重要性、漏洞利用直接造成的影响、漏洞利用条件等进行评判。比如核心系统可利用前台SQL注入漏洞的评级,应该比核心系统管理员之后可利用的SQL注入和一般系统前台可利用SQL注入高,对应的奖励机制也会更高。对于奖励机制,直接进行RMB奖励会更吸引白帽子的参与度。
· src活动:漏洞接收数量直接取决于参与白帽子的数量,衍生开可能涉及到平台影响力、奖励机制等因素。白帽子拉新、白帽子促活、每逢佳节奖金翻倍、月/季/年度额外奖励…需要有规划、有吸引力的发起线上或线下活动,保持与白帽子的联系。
· 其他事项:把跟白帽子的关系处理当做一项正式运营工作,给予白帽子感谢与尊重;注重在安全圈内的品牌,加入生态圈,与其他SRC一起活动,能吸引更多白帽子;制定内部漏洞审核和修复效率,别让线上漏洞暴露太久,也别让白帽子等待太久。
企业一般都会部署安全设备,常见的有安全审计。