甲方一线安全小兵的一些安全思考

一、背景

先说一下自己的情况,大学的时候就读于国内普通211大学的信息安全专业,从毕业算起在安全圈已经混迹了近四年,毕业后在区域型国家队呆了1年多的时间,然后掏槽到大型金融公司的互联网板块工作至今,近三年的甲方工作然我对甲方安全有了不一样的认识,把一些想法写下来算是对自己工作的总结,纯个人想法,如有错误望指出。

 二、甲方公司组建安全团队的目的是什么

  • 公司门面:

其实很多时候问甲方公司负责人为什么要安全团队,给出的答案很可能是因为我们需要、或投资人需要、或告诉用户我们有安全的能力,其实说白的就是为了门面、为了拉投资、为了告诉用户我们有安全团队,但是否真正重视安全就要打个问号了。不过幸好我们公司对安全还是比较重视的。

  • 安全保障:

甲方公司安全和核心需求就是保障业务的正常运行不发生资损、保障数据不被篡改、保障用户隐私不被泄露。

  • 同业竞争:

每个公司都是合法守规的吗?这不见得吧。而且部分公司还存在商品价格竞争关系,防止其他公司通过非法手段获取公司信息和合法手段爬取信息也成了安全的一部分重要工作。

 三、甲方公司安全团队工作包括哪些

我所理解的甲方安全团队主要的工作内容包括:运维安全、传统安全、业务安全、安全制度,由于我本人是做纯技术的,很多的管理制度方面的东西接触不多,接下来的内容可能主要以我个人的工作内容为主。

 四、安全工作的原则

我经常在想甲方安全存在的意义是什么,是卡着业务方,只要存在一点安全问题就不让其上线吗?显然不是,安全也是要讲边界效应的,要考虑安全可能造成的风险和该业务创造的收入,如果一个可以营收1亿的收入的业务存在10万的安全风险,你说要不要让他上线呢?当然安全不能这么简单的计算,但安全团队和整个公司的营业能力是一荣俱荣一损俱损的关系,不能因为怕出安全问题,怕担责任而影响公司业务,如果公司的干部下去了要安全团队干什么。所以我认为安全团队的工作原则是:如何在最低风险下保证业务正常上线和平稳运行。

 五、安全团队的工作方法

  • 责任上移

上面说到了安全团队的原则是在最低风险下保证业务的正常上线和平稳运行,但最低风险不代表没风险,上线出问题基本还是安全团队背锅,那应该怎么办?责任上移。就是在产品上线之前提前和业务方及相关领导报备,确认上线后风险。有领导背书安全就好做多了。

  • 安全kpi

安全推行不下去的主要原因一是领导不重视,二是各业务线没有安全kpi,个人认为安全kpi必须和公司高层争取,保证安全团队在各业务线有话语权,才能推动业务线及时修复安全问题。

  • 人际关系的重要性

安全团队、内控团队和风控团队我觉得是公司最拉仇恨的三个团队,如何处理和各业务线的人际关系显得格外重要,如果人际关系处理得好,工作就会很好开展,但目前来看情商高的安全工程师好像比较少。

  • 甩锅与背锅

安全团队基本上是公司主要的背锅部门,关于甩锅这件事我认为就是该甩甩该背背,有的时候可能背锅比甩锅更好。

 六、SDL实践

如今互联网产品的迭代速度远远超过了互联网刚兴起时候的速度,产品从提出到上线可能只有一两周的时间,且现在安全人员招聘困难,公司出于成本考虑也不可能招很多的安全人员,所以完全实现SDL是不现实的。 那么什么时间点安全介入,如何安排安全的工作重心就十分重要了,如何在最低风险下保证业务正常上线,成了安全人员应该关注的问题。

  • 安全介入时间点

以目前的经验来看,安全介入的最好时间点是开需求分析会的时候,这个时候产品方只对目标产品有个概念上的雏形,并没有到开发阶段,这时提出安全的注意点既避免了事后返工、开发同事对安全的建议也更容易接受。但有一点要注意,需求分析会一般都会开很长的时间,而安全的方面的讨论可能只占其会议时间的一小部分,对于安全人员来讲非常浪费时间,所以建议只参与改动量大、业务关联方多、业务逻辑复杂的需求分析会,在我看来最好的方式是让产品方知道安全的厉害关系,需要安全介入时让产品方主动找你或单独找产品方了解产品需求。

  • 安全工作重心

说完了介入时间,再说下工作重心。我觉得安全团队应该将大部分注意力放在新增功能上,老功能做定期的排查就好了,但定期的排查非常重要,尤其是外部接入的部分,我自己就在这地方栽过跟头,由于外部接入方修改内容未及时通知我们且存在安全问题,导致我们产品存在安全问题。

  • 安全培训

个人感觉非常重要,培训内容不仅是安全常识的普及,更重要的是开发的注意事项,比如哪些是危险函数、登录逻辑、关于本业务的逻辑注意项等等,能针对各职能部门分开做安全培训更好,更有针对性。

  • 安全测试

安全测试介入时间:目前针对特定功能的讨论和功能测试后、产品发布前。在我们公司一般测试的发起人是功能测试,及在功能测试人员做完功能测试、业务功能基本调通后发起安全测试。当然如果要做静态代码扫描的话要又开发发起。

  • 公布安全基本要求

把这部分内容放到这里我觉得是有必要的,应该相当于培训的一部分补充吧!公司很多开发并不清楚公司、监管等的安全基线标准,导致开发出来的系统不符合公司的安全要求而需要整改是一件既蠢又浪费时间的事。

  • 安全归档

安全归档有两个目的:一是成为各业务线和安全人员的kpi标准,方便业务线和安全人员查看其负责团队漏洞数漏洞修复率等指标;二是作为经验的沉积,和下次安全培训的重要参考。

  • 系统生命周期

每一个上线的应用应建立一个速查表,表格内容应包括:上线时间、下线时间、正在使用应用和一下线应用,并定期核对系统是否下线,确保没有一个系统遗漏。

 七、安全工具化

因为甲方之前的工作经历,最开始的时候其实对工具化特别不感冒,感觉手工做安全测试更灵活,更有针对性。但这种观点已经在慢慢改变,原因是在甲方做安全和乙方有很大的不同:一、甲方的盘子比较大而安全人员少,很可能一个安全人员要对接几十个开发,纯手工做效率太低;二、甲方重复性工作比例大,比如日常检测,几乎就是功能反复看日日看,看都看烦了。三、甲方业务更单一,工具检测更有针对性。所以甲方安全的工具化更有优势,且目前来看安全团队工具化是大趋势,也是甲方安全团队进化的标志。

 八、最后

行了,就写到这把,写了一下午完全没有一点技术,就是总结下这近三年工作,并发表下自己的观点,希望大家多多指正。

 

 

发表评论