- 对本书的赞誉
- 序一
- 序二
- 序三
- 前言
- 第一部分 安全架构
- 第 1 章 企业信息安全建设简介
- 第 2 章 金融行业的信息安全
- 第 3 章 安全规划
- 第 4 章 内控合规管理
- 第 5 章 安全团队建设
- 第 6 章 安全培训
- 第 7 章 外包安全管理
- 第 8 章 安全考核
- 第 9 章 安全认证
- 第 10 章 安全预算、总结与汇报
- 第二部分 安全技术实战
- 第 11 章 互联网应用安全
- 第 12 章 移动应用安全
- 第 13 章 企业内网安全
- 第 14 章 数据安全
- 第 15 章 业务安全
- 第 16 章 邮件安全
- 第 17 章 活动目录安全
- 第 18 章 安全热点解决方案
- 第 19 章 安全检测
- 第 20 章 安全运营
- 第 21 章 安全运营中心
- 第 22 章 安全资产管理和矩阵式监控
- 第 23 章 应急响应
- 第 24 章 安全趋势和安全从业者的未来
- 附录
5.8 安全团队与其他团队的关系处理
信息安全工作中,绝大部分的落地工作都非信息安全团队自身可以独立完成,而是在其他团队内完成的,需要开发、运维、科技管理等其他团队的密切合作方可达成目标。因此,与其他团队的关系处理,已成为信息安全团队不可回避的工作,甚至在某种程度上成为成败的关键。
1.基本原则
(1)冲突不可避免,但目标必须一致。
任务重、资源紧是科技部内各团队的常态,由于各自工作目标、工作重心、汇报路径的不同,导致其他团队与信息安全团队不可避免会存在一定的冲突。但信息安全工作是保障系统稳定运行、防范攻击的底线要求,所以各个团队必须统一思想,把信息安全的目标作为自己团队的目标之一,认识到大家只是不同的职责分工,但最终目标都是在确保守住风险底线的前提下,大家一起应对不确定性,通过共同协作、互相补位以实现更好的发展。
(2)不得罪人的信息安全团队,不是好的信息安全团队;把天下人得罪光的信息安全团队,也不是好的团队。
信息安全团队之所以要与开发、运维、科技管理等团队保持相互独立,就是要发挥检查和监督职能。如果处处做“和事佬”,生怕得罪人,不敢出具反面意见,信息安全团队只会“和稀泥”,难以体现专业能力。但是,如果时刻以“东厂西厂”的心态来工作,也会成为众矢之的,得不到大家的配合。因此,必须寻求一种平衡,把控住“度”,在守住风险底线的前提下,在关键问题上表达专业意见,在非关键问题上可以适当让步,大家互相妥协,达成一致的目标。
(3)君子和而不同,小人同而不和。
信息安全团队与其他团队共同做事的时候齐心协力,事情做完后大家互不影响,给对方独立的空间,这就是和而不同。比较好的做法是,心理上对别人和睦友善,但是在对待问题的观点上不会一味地附和别人,有自己的主见,能体现专业性。同而不和则恰恰相反,心底可能很嫌弃这些人或事,但在平时别人表达观点的时候为了使自己看起来和大家一致,而一味附和他人观点,这样的做法很难保持自己的独立性和专业性。
(4)风险管理必须以促进业务发展而非阻碍业务发展为目标。
信息安全团队不能一味与其他团队对立或总是“Say no”,而是要更多的思考,如何合法合规地帮助其他团队达成目标。要懂业务、懂开发和运维等科技的其他职能,要深入一线了解现场情况、了解一线的困难和资源状况,帮助他们想办法以最小的代价、最高的效率做到合规。如果只是在旁边观望、挑刺,指手画脚地要求整改,就很容易把自己孤立起来,得不到其他团队的支持。
2.安全团队关系管理
(1)安全与开发
信息安全团队与开发团队,可能是“冲突”最多的两个团队。因为开发团队的天职是高效满足业务需求,如果需要更多地考虑安全控制要求,很可能导致逻辑控制复杂度更高,客户体验受到制约。
信息安全团队必须深入了解安全团队所面临的业务压力,以同理心对待,深入了解技术架构和业务逻辑,并帮助开发人员考虑如何采取最优方案,取得安全性和效率、客户体验的平衡。全生命周期的安全管理措施,制订起来复杂,执行更是艰难,所以信息安全团队要协助开发人员,针对不同安全级别的应用系统,采用不同复杂程度的安全开发基线,避免“一刀切”导致的资源浪费和项目周期延长。
(2)安全与运维
信息安全团队与运维团队,是目标最一致的两个团队,因为运维人员的天职也是风险控制。信息安全团队必须深入了解运维工作流程,理解每一项运维流程设计的必要性,掌握运维关键风险,并在日常工作中帮助运维团队发现风险,提出风险控制的措施,继而通过持续的检查,帮助运维团队巩固落实风险控制措施,降低风险隐患发生的可能性。
(3)安全与科技管理
信息安全团队与科技管理团队,在开发和运维管理的职能上可能会略有重叠。例如,有些安全整改工作同时也是科技管理团队制订的部门工作计划表中的任务,如果双头管理,会给开发和运维团队造成困扰,也会在整个部门的工作上形成重复浪费。所以安全团队应该与科技管理团队多沟通,对于同一件事情大家只开展一次,通过信息的共享实现高效管理。
另一方面,科技管理团队也会有风险。例如,信息科技治理的合理性、部内制度流程的合理性、预算和商务管理工作的合规性、IT 资产管理的合规性等,也需要安全团队来检查把关。信息安全团队还必须懂一些科技管理、财务和资产管理等知识,才能更好地发现科技管理中的问题并提出解决建议。
(4)安全与业务
信息安全工作是“后台中的后台”,与业务打交道的时候往往就是在“Say no”的时候,或者是主动出击对业务进行数据安全检查、培训教育、病毒防治等场合。所以业务人员对信息安全人员的感觉很可能是“见到就知道没有好事”。信息安全人员需要摆正心态,向业务人员耐心解释自己工作的出发点和价值。同时需要多学习一些业务知识和业务相关的监管要求,把握住“业务风险”和“科技风险”的边界,属于业务风险性质的决策权交还给业务部门,不要越界干涉,做出“吃力不讨好”的事情。
(5)安全与外包
外包风险是金融企业信息科技风险的重要组成部分之一,信息安全人员经常需要对外包风险进行检查和评估。对于外包人员的管理相对金融机构内部人员来说更难一些,因为没有绩效考核、薪酬奖惩的权利,而且外包人员流动性相对较大,外包风险的处置很可能治标不治本。
信息安全人员需要形成常态化的外包培训机制,经常性、分批次地对外包人员进行信息安全意识教育;对于外包团队的负责人要先开展教育,提高安全意识水平;在合同中增加条款形成法律性的约束,要求现场人员个人签署保密协议;日常检查频度需要提高,最好每月开展外包检查,确保工作长效机制的建立。
(6)安全与监管
金融机构的信息安全团队通常是信息科技部门与监管沟通的“窗口”,一定要掌握好与监管沟通的频率和方式方法。要建立定期沟通报告的机制,多参与监管组织的活动(例如培训、会议、课题研究等),平常就“多露脸”,使监管能了解本企业信息科技工作的亮点,不能等到出事了才第一次被监管感觉到“你的存在”。
针对本企业已知的风险,也需要根据实际情况适当向监管提前报备,同时提供自己的解决方案和整改计划,可以考虑向监管请教同业的实现方式,请他们直接指点,或者创建同业交流的平台,或者安排与相关领域先进同业直接的学习机会,这样就能争取到监管的帮助、支持和理解,减少“意外惊喜”的发生。
不管是与哪一类团队的沟通,信息安全团队都切忌把自己当作局外人,而应设身处地地站在对方角度考虑问题,把发现问题当作双方的目标而非仅仅信息安全团队的绩效,把问题整改当作双方必须共同达成的任务而非仅仅其他团队单方面的工作。这样方可建立良性的沟通机制,从而使得信息安全工作机制得以有效运转。
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论