【企业安全】企业安全架构建设

1 安全组织架构

在甲方的安全工作中,重点自然是在企业的安全建设上,但是为了能持续不断的输出,安全队伍的建设变成了不可或缺的一环。成员的能力决定着企业安全的高度,合理的安全队伍配置是整个建设之路上的引擎。

1.1 理想中团队

按照角色与工作职责,安全相关的岗位可细分为:CSO、安全架构、安全审计、安全测试、代码审计、安全开发、安全运维、安全运营、安全风控等方向,比较理想的安全团队并不是要求设置以上全部岗位,而是在开展相关工作时需要涉及这些专业技能。根据公司的大小差异,各个岗位的名称与headcount也都不太一样。

1.2 现实版团队

“理想很丰满,现实很骨感”,这句话尤其请乙方安全工程师注意。为什么是乙方安全工程师呢?因为很多人以后都希望转到甲方。虽然平时有接触不少客户,但若不是项目负责人或不是参与安全评估类的项目,很少清楚知道客户所处环境。很多甲方公司或许并没有专职的安全人员,或许仅有临时工,此类场景常常出现在传统企业、非互联网过渡到互联网的企业中,所以在准备跳槽时对企业的选择需要谨慎。

作为掌舵者的CSO重要性不言而喻,由于具备实战能力与经验兼备的CSO较少,从成本与安全需求的迫切性出发,不少企业在该职位上也没有留下足够的薪金,也导致了目前比较普遍的现象:

安全由运维leader负责,向cto汇报;安全由测试leader负责,向cto汇报;安全由开发leader负责,向cto汇报;企业内部由运维/测试/开发参与安全项目,像上一级负责人汇报…

  • 安全由运维leader负责,向cto汇报;
  • 安全由测试leader负责,向cto汇报;
  • 安全由开发leader负责,向cto汇报;
  • 企业内部由运维/测试/开发参与安全项目,像上一级负责人汇报…

术业有专攻,即使很强大的leader在遇到一些安全项目的决策时,也极有可能持保守态度,在没把握情况下与其犯错不如不做。相比专业的安全人员,这无疑在一定程度上限制了企业安全的发展。此外,由于对安全领域的不熟悉,在与上级领导沟通、对安全项目上的投入等方面表现不足,往往也会成为制约企业安全建设的因素。

还有一种较为常见的场景,公司中并没有设置CSO这一职位,该职务一般由安全部经理甚至有发展潜力的安全工程师担任。所谓的潜力简要概括为:

1.3 安全架构组

组成:CTO、CSO、架构师、安全架构师、中间件等各部门领导

职能:重大安全架构决策,安全相关规章制度评审。

1.4 安全接口人

成员:各业务部门负责人(可设置AB岗)

职责:负责所在部门/业务线安全问题的对接、沟通、跟踪。

2 安全架构规划

安全架构规划是一个非常复杂与庞大的话题,由于水平有限以下观点仅供参考。在一些对外交流中,有不少人会参照书本上或其他公司分享的案例,从标准体系(27001&等级保护等)—>具体工作的视角进行规划。但作为安全建设从头开始的体验者,深刻感受其可行性、见效率与不足之处。

2.1 安全风险发掘

在实习的时候,记得当时的部门领导(上交大网络安全学院老师)说过:信息安全从业者就好比是医生,企业有问题需要我们去出诊,首先就是要根据病症进行相关检查分析才能对症下药。那么甲方安全工程师做安全就是医生给自己看病,需要不断的搜集异常症状并进行分析判断是否有问题,即安全风险发掘。以下是对常见企业安全风险的简单梳理:

要做到实用性,往往要求熟悉公司网络环境与业务形态,此外还需要一定的嗅觉性,追究其根源便是:意识、经验与视野。

2.2 外部经验交流

在一次企业安全沙龙中,看到了蘑菇街的安全项目蓝图,并从中得以借鉴。通过前期安全风险挖掘的积累,信息安全组内进行头脑风暴并对相关项目进行梳理,把相同实现效果的项目整合成一大类,再把各个大类聚合在一起,便有了初始的安全架构规划图:

安全是动态的、持续性的,需要保持一颗善于发现问题、思考总结的心,不断完善企业安全的整体画像,不断优化相关环节的同时也进行项目的推进。

3 安全工作推动

3.1 领导支持

安全工作的推动是一个自上而下的过程,在建设的伊始便是与上层领导沟通,并争取获得必要的支持,具体理由可参照【企业安全:企业安全建设需求】进行分析与汇报。此外如果是项目负责人,应该自己先竭尽所能的去推动,实在有困难时邀请领导出面参与会议或回复邮件,也是提升工作效率的一大利器。

3.2 安全运营

在企业安全建设初期,除了救火工作外还建议开展体系化的、丰富的安全意识培训。人是安全的知名薄弱环节,因为员工的安全意识参差不齐,所以需要进行多个渠道(邮件、即时通讯工作群)、多种方式(海报、易拉宝、动画片、暴漫)、多种内容(通用安全意识、最新安全威胁、行业安全情况)等方面的长期"洗脑"。这里把安全意识的培训推广工作加入到了安全运营的一个环节,除此之外安全方案的不断优化、漏扫插件的更新、waf规则的即时添加调整、SRC的推广都应该属于运营范畴。

3.3 做事思路

根据已经参与或负责的安全项目发现,在甲方做事情很讲究做事的思路。以下简要的记录了深有体会的几个小点:

1)城市包围农村,结合多个部门一起推动

在推动专项安全项目时,会出现不好对付的部门。这时候不能硬碰硬,从存在安全问题的部门做起,其次是支持安全工作的部门,接着再按照实现难易程度与花销依次排序,把最难推动的部门放最后。推动过程中,不断及时汇报项目进展情况,比如本周推动90%的部门完成安全改造,剩余10%的部门尚未整改。迫于压力,一般情况下10%左右的部门也会尽快加入进来。

2)鼓励+奖励 > 惩罚

面对业务部门时采用鼓励与奖励的方法会好过惩罚。不少人有时会产生一种错觉,凭借自己的技术强力把业务方怼回去并暗自高兴,然而我的想法确是和业务方友好相处甚至做朋友,安全的出现是为了业务变得更加安全更好,而不是阻止业务前进的步伐,当高危漏洞降级至没法再降比如低危时,可以注明情况并通过安全测试。不过需要补充的是,礼让、文明合作是有尺度的,基本的原则不能丢,某些情况下不能轻易妥协。

3)主动出击引导业务进入安全节奏

一般的甲方可能只有一个或几个人懂安全,无论是开发大神还是运维大神都不会太懂,所以信息安全组的成员更应该主动的去找相关人员沟通,交流遇到的安全问题以及结合实际业务场景提出合理的安全建议,将安全早点带入到各个业务场景中。在日常的工作中,效率值的排名一般是:直接找人当面沟通 > 电话沟通 > 即时通讯工具沟通 > 邮件沟通,当然也可以几种相结合,主动想办法提升工作效率。

*************** 未完待续 ***************

在【企业安全】系列文章中,最怕出错的其实就是本篇章。因为涉及到安全组织架构、安全架构规划等具有相当高度的内容,很可能会因为视野狭窄与经验不够丰富等因素给大家带来误解,如有错误之处请留言指正。

原文发布于微信公众号 - 我的安全视界观(CANI_Security)

原文发表时间:2018-01-21

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏极限编程

深入解读敏捷宣言

犹他州(Utah)的雪鸟城(Snowbird)是一个不太可能发生软件革命的地方,它位于盐湖城外约25英里的地方,一点都不像硅谷:既不以阳光和温和的气候闻名,也不...

923
来自专栏人称T客

成功科技产品的三大支柱

T客汇官网:tikehui.com 原作者:Nir Eyal 编译 | 李哲 ? 如果你开科技公司是为了赚钱,那么很可能你的数学不好,或者是妄想症发作。因为从...

2896
来自专栏JAVA高级架构

想要成为一个合格的架构师?看这篇文章就足够了......

在互联网圈,架构师这个名号的火热程度堪比产品经理,它在产品经理没火之前就已经风生水起。

993
来自专栏BestSDK

一周简报|高德地图发布AI引擎,可应对各种复杂环境

高德地图发布AI引擎,可应对各种复杂环境;开源软件Torch神奇功能:可还原马赛克;友盟+推出第三方广告效果监测工具U-ADplus;网易易盾正式发布,以人工智...

4078
来自专栏程序你好

谁说程序员是吃“青春饭”的?

1426
来自专栏华章科技

YC合伙人:微信的发展堪称疯狂,这7点值得学习

当创业者被问及最想做出什么样的产品时,他们越来越多地把目光投向亚洲,其中微信当属他们最梦寐以求的产品之一。我的朋友和前同事Connie Chan将微信形容为ap...

661
来自专栏TEG云端专业号的专栏

【paterzheng(郑礼雄)】每个阶段都去尝试做一些改变

‍ ? paterzheng(郑礼雄),2004年加入腾讯,运营老兵一枚,先后在计费领域和数据领域从事研发及运营工作,他自我介绍说本是开发出身,被人误导转做运...

3024
来自专栏前沿技墅

从 Google CRE 谈运维的服务意识

花名“谦益”,是公众号“Forrest 随想录”的作者,多届 ArchSummit 运维专题明星讲师和优秀出品人,TGO 杭州分会会员。目前专注于云计算和人工智...

1392
来自专栏VRPinea

华为完成首个5G实验网下Cloud VR业务验证,VR云端系统要来了?

4018
来自专栏人称T客

语音控制:企业计算的下一个重大突破

如果说2007年 iPhone 的发布开启了近十年来消费者信息传达被屏幕和视觉统治的时代,那么,语音将成为继智能手机之后企业科技界下一个最大的颠覆。

591

扫码关注云+社区