标签归档:原生安全

企业安全建设的体系思考与落地实践之二

前言

不知不觉中距离上一次发文已经四个多月了,这四个月不仅我个人的生活和工作发生了很多变化,我想大部分人的生活因为这场突如其来的疫情也发生了巨大变化。不过,这个世界每天都在“悄无声息”地变化着,而作为一个“有志的技术青年”,“不悲观、不放弃、勤思考、擅质疑,多实践,频总结”,并积极乐观的生活与工作着才更加重要。

今天这篇文章没有太多的技术细节,也可能会让你觉得很枯燥,甚至连文章的标题我都懒得起(只是临时征用了一个之前的文章标题《企业安全建设的体系思考与落地实践》并“敷衍”地加了个“二”,其实二者关系并不大),但是我觉得如果你实在无聊也可以读一读,或许给你些许启发。

思考

在讲述企业安全建设的演讲PPT和书籍中,我们经常会见到各式各样的建设体系和分类,包括我自己写的这一篇《企业安全建设的体系思考与落地实践》,初看觉得有点道理,但是细想下来又让人有一种“食之无味弃之可惜”甚至是“言之凿凿有何卵用”的感觉。

那么怎么来分析和思考这个问题呢?一种最为简单的方法就是“5W(5 Why)根因分析法”,即深入地渐进式地问自己至少5个“为什么”从而挖掘问题的根本原因。

“为什么看似有道理而实际没卵用?”因为其过于强调解决安全体系建设中遇到的共性问题,而忽略不同企业间的差异性问题。

“为什么重共性、轻异性会导致这个结果呢?”因为大部分企业的安全建设真正的难点不在于共性问题的解决而在于怎么寻找解决差异性问题的思路和方法。

“为什么差异性的问题的解决才是企业安全建设的真正难点?”因为这种差异性问题是由不同企业的发展阶段、业务形式、人员管理等多方面因素所造成的,且没有办法在外面直接找到解决这些差异性问题的安全建设方法。

“为什么企业的发展阶段、业务形式、人员管理等多方面因素会造成这些差异性问题?”因为企业的发展阶段决定了安全在企业发展中所处的地位和价值的不同,业务形式决定了企业面临的安全风险的不同,人员管理决定了企业对安全的认知能力的不同。

根据以上一系列的自问自答,我们似乎找到了产生这类感觉的根本原因是由企业的“发展阶段,业务形式,人员管理”的不同所造成的。那么下一个很自然的问题,怎么才能解决因为这些不同所造成的安全建设过程中的困境呢?笔者认为一种方法就是“对症下药”,将安全体系建设根据企业的发展阶段融入公司业务发展和人员管理之中。

实践

本节笔者将试图以自己当前阶段有限的知识和经验来谈谈具体怎样“对症下药”(注:随着笔者自身认知的提升,未来可能会有更有效的“药”)。既然是“对症”,首先就得知道当前企业具体处于什么阶段。笔者将分别针对以下三种阶段的企业聊聊怎么“下药”。

小型创业公司

这类企业的业务形式往往比较单一,可能是某个特别细分的领域;人员管理相对简单,一般都在50人以下。针对这类企业,谈复杂成熟的体系化安全建设还为时尚早,但是这并不意味着安全不重要,相反这正是安全体系建设的早期阶段,投入少见效快。这时,安全建设的重点应该是保证业务的可用性和完整性。企业的大部分网络资产是员工的办公电脑以及公有云服务,因此提高员工的安全意识以及利用好公有云服务提供商的安全解决方案(例如:WAF,Anti-DDOS,主机防护,堡垒机等)对于企业的安全能力建设必然会事半功倍。因此,周期性的安全意识培训和宣讲,标准化的业务上云流程(资源申请,配置管理,云上安全解决方案等)将是小型创业企业的安全建设的“良药”。

中型传统公司

这类企业一般在某个行业里已经深耕了多年,业务形式比较确定且变化少;人员相对较多,管理也比较稳定。由于企业已经运行了多年人员管理较为固化加之业务变化少,很容易造成其对于安全的体系建设的内在动力不足,更多的驱动力是来自于外在的监管要求(比如网络安全法,等保,GDPR,以及各种行业合规要求等)和安全事件的发生。对于这类企业,安全建设的重点应该以外部监管的要求为支点,以实际安全的落地要求为抓手,以发生的安全事件为“契机”,循序渐进地推动企业往体系化的安全建设的方向去走,将安全的防御策略融入到业务场景帮助业务解决实际运营中遇到的各种安全风险(如:法律法规对隐私数据保护的要求,行业合规对客户数据处理的规定等),并积极协助和推动业务系统往更加安全的方向迭代和升级(如:利用传统企业往IT化、云化的方向演进的趋势,积极融入安全的建设思想,系统性地解决业务系统升级过程中的安全痛点)。同时,通过外部的要求和内部的迭代演进,把安全的认知意识通过已有的成熟的人员管理体系(如:内部培训,绩效考核,工作方法,奖惩制度等)逐步固化到每一个企业员工的日常工作和思考方式中。这个阶段的企业,切忌不可盲目跟风当前“最流行”的安全概念,如果连最基本的日志都收集不全、边界安全都没完善,还谈什么威胁情报、Anti-APT、Red Teaming、零信任之类的,此时这些不过是“镜花水月”、“空中楼阁”罢了。

大型互联网公司

这类公司的业务繁杂且变化迅速;人员繁多且管理复杂。其一般已经具备了相应的的安全防御能力,安全体系建设也已经基本完成。这些公司最大的问题是已有的安全体系无法快递地适配或者说是跟进业务的发展,这就造成快速发展的业务与缓慢跟进的安全建设之间的矛盾。笔者认为,解决这种矛盾的方法之一就是安全建设融入业务发展,业务发展驱动人员管理,人员管理促进安全建设。

640

安全建设融入业务发展

我们常常看到各种安全建设体系里提到很多细分领域如:“安全治理”、“安全合规”、“数据安全”、“SDL”、“基础安全”、“内网安全”、“应用安全”、“安全运营”、“云安全”等等,每个领域往往都是各自为政、单打独斗,相互之间也会彼此独立,却很少能看到如何将这些所谓的细分领域彼此关联并融入到具体业务发展中去。很多时候我们在谈论安全建设时很容易陷入脱离业务来谈安全的怪圈,没有真正地理解业务所面临的的安全困境和痛点,所以需要从“外挂式安全”变成真正的“原生式安全”。

所谓“原生式安全”,并不是什么新的概念,而是将安全建设伴随着业务发展的整个生命周期融入业务的产生、设计、上线、运营、迭代、下线等各个阶段之中,旨在让各个细分领域彼此关联形成一个互相联动的整体。

举个例子,一个新业务的发展往往经过以下流程:业务团队根据市场调研的结果挖掘出客户需求;研发团队根据需求设计并持续开发和交付相关的业务产品和支撑系统;运维团队维护和管理已交付的业务系统;运营团队从上线的业务系统中拉取并分析客户数据做持续运营。我们可以采取下面的方式将安全建设融入到业务发展的生命周期里。

一、安全合规和治理所制定的安全政策既要帮助业务团队确定需求的合规性,也要将各种安全政策和标准通过工具的形式融入到软件/系统开发的SDL流程中(如:CICD流水线),让研发团队在系统架构设计之初通过自动化工具即可了解所设计系统的潜在数据风险等级以及相应的标准化的数据处理方案(如:传输加密与否?存储加密与否?何种类型的加密算法?哪些可用的公共加密组件?哪些可用的专有敏感数据存储系统?等等)。

二、在编码阶段提供给研发团队默认安全配置的代码仓库模板和相应的缺省加固后的开发框架以及统一的认证、授权、密钥存储等公共安全系统或组件。

三、在测试阶段提供集成在流水线之中的动/静态安全测试工具。

四、在部署阶段采用自动化的方式申请资源(如:统一的经过安全加固后的操作系统或容器镜像等)和配置参数。

五、在上线阶段所有资源信息自动同步纳管CMDB并与HR系统中的员工(服务owner团队)联系方式关联。

经过上述方式,我们便可以将安全政策和标准融入业务威胁建模之中,公共安全组件和框架融入业务开发之中,安全测试融入业务测试之中,安全加固融入业务部署之中,安全监控和纳管融入业务上线之中,并最终形成一个标准的具备“原生式安全”的业务发展流程。

业务发展驱动人员管理

随着自带“原生式安全”属性的标准业务发展流程的成熟,必定会对人员的要求越来越高,那些安全意识薄弱的人员会被不断教育或者逐渐淘汰,人员的安全认知能力也会因为成熟的流程而逐渐被提升并固化到日常的工作生活之中,最后变成了每个人员的安全潜意识。

人员管理促进安全建设

当具备安全潜意识的人员越来越多,他们就有可能自主发现更多潜在的安全问题,并输出安全需求,从而促使安全建设的持续发展和迭代,形成一个良性的闭环。

后记

洋洋洒洒写了这么多,其实想表达的意思就是一句话:安全建设应该以“客户”为中心,从安全的受众出发,彼此融入,协同发展。

笔者的一直以来的安全观可以总结成以下几个词:原生(Security-native)、身份(Identity)、自动化(Automation)、情报驱动(Intelligence-driven)。

参考