0x1本周话题
话题：默认安全的力量比想象中要大很多，我觉得也可以扩展到其他领域。例如在居家领域就引申出一个叫默认整洁的概念，制定一系列的计划和原则，就可以把家庭整洁度保持在一个舒适水平。我们正在实践，别的领域也在探索，比如在时间管理上“默认高效”，在身体方面“默认健康”，在生活方面“默认幸福”，在财政方面上“默认发财” 等，有新的进展我再和大家汇报！
A1：像是一种习惯？如用户同意界面有“默认勾选”。
A2：感觉像是破窗理论的延伸，一些暴力犯罪的发生，都起源于一些微小而又明显的的破坏行为被忽视。一扇未被修复的破窗，就等于是在向外界表明，根本没人在意这些窗户，这样即使你打碎了更多的窗户，也不会付出任何代价，而且通常这还很有趣。防止犯罪发生的一个成功策略是在问题很小时就解决。这就是犯罪心理学中的破窗效应，就像一个系统的默认口令是123456，如果一直没有人去修改，就等于再向外界表明，根本没人在意这个系统的安全性，这样即使有人破坏了这些系统，也不会付出什么代价，而且还很有趣。
Q：请教一下这个默认落地在什么地方呢？如果大量历史包袱，咋默认呢？
A3：默认的意思是从默认规则开始生效的时候起算吧，感觉还是从新建系统搞起，比如默认安全的口令策略、基线模板、acl 缺省 deny 等等，老系统只能慢慢改了。
A4：是的，先做增量，存量在有变更或其他合适节点介入长尾治理。如果强势，也可以打一波治理工单，通晒各技术单元完成率。
A5：默认安全一直是我们讨论的主题，在日常管理中应用很多，比如在防火墙策略上一定会有一条默认双向 deny 兜底，主机、中间件、数据库的安全基线，web应答规范，应用开发规范，通用功能的设计规范，甚至于开发安全包，都是在解决一个基本信任的问题，零信任和白名单是应用这个原则比较好的机制，也是技术能力和管理水平的体现。
这一类和配置强相关的工作，都是按照强制要求新建，逐步治理和变更存量，且变更存在一定的风险，需要评估和验证。
Q：默认安全可不可以理解是网络资产自身拥有的安全能力，而不是依靠于外部的防护。
A6：认同默认安全，或者叫主动安全，前置安全。安全和发展可能正在做一个变更。
第一阶段，要安全还是要发展，倾向先发展，安全外置逐步保障，这是发展的安全。
第二阶段，安全还是发展，倾向先安全，安全内置，成为安全的发展。
当然，第一阶段可能也不是主动选择的，是已经发展起来了（从cs到bs到移动端到分布式），安全在追；第二阶段安全往前走一些，尽量前置，走到操作系统层就成为安全基线，走到软件层就成为sdl。
默认安全对安全人员开发以及对业务的理解能力要求比较高，如果有经验丰富的，有可能在一个行业形成典型案例。越是专业领域，越需要，缺点是越准确的默认安全通用性越弱，不好平衡。最极端的例子就是卫星安全或者工控系统安全，不需要的全部屏蔽。个人的一点理解，不一定准确。
说个可能和技术不相关的，随着系统复杂度增加（从单体到分布式到微服务），同样功能目标，熵值是增大的。增加功能和目标，也是增大。
安全加入是不是相当于降低系统熵变得稳定，这个我也没搞太清楚，还在学习中。若是这样，默认安全也是在降熵。
A7：个人直觉上，默认安全、主动安全还是分行业、分场景、分阶段的。就像我做个芯片出来，没有安全功能，但是功耗低、性价比高、功能性能对于一般家用电子设备够用，也能卖不错。但是如果芯片要用在高端客户、重要单位，那安全就是卖点、核心竞争力，就要默认安全。
我感觉只有安全是核心竞争力、重要成本要素、关键质量要素的时候，才会搞默认安全、主动安全。比如软件编码，写支付代码的都会防御式编程，其他业务很难，后向检查闭环成本也太高。
A8：基于业务架构和技术架构，是否可以出一个默认的安全架构，尽量从非功能性需求的角度给研发侧一个场景化的配套解决方案。
A9：降熵这个分析上升到了理论层面。确实是，大家一般都认为引起安全事件的弱口令、Nday漏洞是低级问题，但要完全规避其实是一个非常复杂的问题。对抗熵增是很难的，是一个系统性工程，只靠人的主动性和自觉性是不可能的，甚至是反人性的，所以需要系统性机制与能力来实现。
还有老生资产的资产问题，谈安全必谈资产，但就是很难实现资产信息的持续保鲜。也是熵增问题。所以我们在默认安全机制上要建立资产准入的系统卡点机制。
A10：复杂度增加是必然现象，熵增也是必然的，是业务复杂度上升、系统各层解耦以后必然，也是分工精细化合作的结果，这个过程无法避免。熵增不是坏事情，但如何让复杂度上升以后安全问题降低比较难，或者说有没有一个安全熵的概念（国内有一些论文在谈这个，但我的理解还不深或者说感觉不能准确的刻画），可以描述默认的安全状态应该是什么。
换句话说，假设真的有一个状态，这个状态安全能做的事情已经到头了，这个时候安全熵减=安全措施总合=默认安全措施。
假设：总体熵=系统功能+系统非预期功能。系统熵=总体熵-安全熵减。系统熵越接近系统功能，安全度越高。
假设系统功能有两个状态，状态1和状态2，系统熵1除以总体熵1小于系统熵2除以总体熵2，则证明状态2中功能增加了，但安全度也增加了，这得去找莱布尼茨老师微积分一套东西。我感觉比较矛盾的是，这个衡量标准不好界定，以上属于学术探讨或者闲谈吧。
A11：想到以前老板评代码，会说这个功能那么简单，不要引入开源一大堆组件又不读，自己写就行了。最近伴随着降本增效，也总有些拆微服务的报道本质都是在降熵。
Q：《数字银行安全体系构建》第12章实战检验基础提出：配套管理机制包含了《红蓝演练报备机制》、《蓝军操作规范/红线》、《数据迭代保鲜机制》等机制可以使演练安全平稳地进行。请问数据迭代保鲜机制具体是指什么？
A12：数据迭代保鲜机制，首先要保证威胁路径是最新的（it资产、网络架构等），保证高危威胁不被遗漏；然后是攻击技术的迭代更新，保证可以涵盖最前沿的攻击技术；红军要及时更新同步威胁路径图中的治理、感知和防御状态，可同步蓝军重点检验验证；蓝军在打点、日常渗透测试、红蓝演练等要及时更新操作行为，这样计算得出的感知、防御指标才更精准。
人员投入，在比例上其实也是刚刚达标，国内大部分安全问题的根源是安全人员投入严重不足。攻击团队我们是叫紫军，目的也是为了防御服务，避免红蓝攻防变成一个信息不对称的对立游戏了。
A13：但老板会说你看别人那么点人也完成了，缺人是常态，大家都缺人。这就很无语，安全自己说投入不足没有信服力。不过老板出了事情别抱怨就行，如果自己投这点资源，自己要有数，平时多去烧烧香。
Q：防守方有防入侵以外的职责吗？想拉齐下范围，比如开发集权系统这种默认就不算；渗透测试、漏洞检测也是攻击队做吗？
A14：防守方范围是网络安全和数据安全各个环节都需要负责，上面说的漏洞测试也包括，攻击方其实算是检验方。
Q：“防御指标”从哪几个维度定义的，以及目前大概能做到什么程度吗？
A15：防御指标首先是从两个大维度分类：一是安全体系的划分维度，包括风险预防(治理)率 、纵深防御率、威胁感知率、止血溯源率等；二是根据风险域划分为网络安全域、数据安全域、业务安全域，这两个维度会产生一个二维矩阵。
指标计算方法，总体逻辑是类似的，先需要根据企业的资产分别情况和威胁态势建立自己的威胁路径矩阵地图，比如要入侵窃取核心数据库的数据有多少条路径，分别经过几个节点，每个段路径上有多少种攻击方法等，在此基础上根据路径的风险优先级进行检验，最后根据检验的结果计算风险预防、防御、感知的覆盖率和有效率等指标。目前我们覆盖了威胁路径图中的高风险等级路径的绝大部分，每个月会产出一版计算指标月报。
上面描述的是概括的逻辑。其实还有一个维度是威胁路径对应的威胁等级，安全不需要应对所有的威胁，只需要应对和检验企业可能会面临的威胁等级以下的威胁路径。可以参考《数字银行安全体系构建》里面13章里的计算模型，13.3.2里也有一些具体指标的计算逻辑示例：
大家有兴趣可以了解一下最近这书里介绍的这个部分，我个人认为还是比较好地回答了安全检验和水位衡量的问题。
虽然这本书写的是数字银行安全体系，但本质还是企业安全体系，只要是对效率和安全性要求高的企业是有类似的适用性的。书里网商银行的安全体系也是在蚂蚁安全的多年实践经验积累的基础上进一步实现的，也是蚂蚁安全切面、可信、复合治理等能力和机制落地的一个实际案例。
每个部分都需要实际检验，检验是否能感知或者防御。当然防守方自评防御和感知等能力尚未覆盖的，就不用实际检验了。
如何进群？
原文始发于微信公众号（君哥的体历）：关于默认安全的讨论 | 总第228周
