自2022年5月起，“诸子笔会第二季”正式拉开帷幕。经过对首届活动复盘，我们在坚持大原则、大框架、主体规则基础上，优化赛制特别是奖项设置和评奖方式。14位专家作者组成首批“笔友”，自拟每月主题，在诸子云知识星球做主题相关每日打卡，完成每月一篇原创。除了共同赢取10万元高额奖金，我们更要聚焦甲方关注，发掘最佳实践，弘扬分享精神，实现名利双收。本期发文，即诸子笔会2022.10月回顾及盘点。

安在征文活动10月主题：过与不及

在累计21天的征文星球打卡中，9位笔会专家共计打卡108次。安全性和可用性是摆在安全团队面前的两座大山，过与不及的平衡就在这两者之间，如何在确保用户体验的同时，最大程度提升安全性是专家们讨论的重点。对此，9位专家针对如何达成平衡、如何应对风险以及过与不及又该如何等方面展开了细致的讨论。

在此摘选个中优秀观点，向各位分享。

如何达成平衡？

►在数据安全和个人隐私保护中有个环节叫做PIA（个人信息影响分析），安全团队在分析公司战略目标和业务目标时可以借鉴，简称为CIA（网络空间安全影响分析）。主要目的是了解公司整体的战略目标和业务分布的轻重缓急，根据业务分析业务运作模式在数字化技术体系下的框架和结构，分析可能面对的威胁、存在的脆弱性，根据业务的规模、投入产出，估算风险的可能性以及最佳的成本配置，找到平衡的目标框架。

►根据帕累托定律，80%的安全能力只需要投入20%的精力就可以达成，如果想让安全在你心中无懈可击，那么可能就需要投入现在的几倍精力。所以我们要把握一个度，这个度就是基于你们对于公司风险的判断，以及对于风险容忍度的判断。

根据灵魂三问的答案，我们很容易就可以把精力集中在最关键的业务问题、暴露在外网的脆弱的服务与API以及包含敏感数据的系统上。我们也很容易将我们的工作分为几个层次，把我们的业务进行分类分级，而不是一视同仁地对待，应该将好钢用在刀刃上，有的放矢。

►创新是基于发展提出的，安全能力在创新面前还是显得滞后，科技在飞，安全在走，貌似不在一个档次上。安全架构一直在不断革新，来解决各种新产生的问题，不过安全技术的研究貌似一直局限在对原始遗漏安全问题的不合理性，以及如何更合理地解决已知未解决的风险。

还有一种说法是科技一直在创新，安全的技术应用或者思维仍是沿用最初的技术积累，仅仅是将已有的安全技术换个框架、换种思维、换种组装方式来应对新技术的安全问题。唯一可以肯定的是随着新技术的发展，企业的攻击面范围肯定会扩大，存在的安全问题也会相应增加，需要关注创新发展和安全保障之间的平衡点。

►企业清晰的认识到他们需要统筹解决它所面临的安全问题，但很客观的一个问题是用户对于安全的认知和偏好是飘忽不定的，他们只知道我要安全，却并不知道什么才是安全的。打个比方，企业为用户提供MFA服务时，用户对于选择使用短信、生物识别技术还是其他手段时并无明显的认知，但当企业为其提供了生物识别技术作为MFA的手段时他们会抱怨说识别率太低、部分场景不好用而主动关闭这部分功能。这对于企业而言会是一个比较麻烦的问题，因为企业都会想着为它的客户提供最好的安全服务，但当最基本的安全需求都无法确定时，企业会在如何投入信息安全资源上产生犹豫，比如前面提到的生物识别技术，即使用户现在认可这项技术是安全有效的，但随之而来的针对这项技术本身可能存在的被滥用的风险又被提了出来。所以现在更多的企业选择了多种MFA实现让用户自行选择，将这部分成本算在整体的安全成本中。

►要掌握安全和发展的“道”，安全和发展不是矛盾体，担心安全风险而放弃新技术是故步自封，新技术的安全风险不能放任不管，也不能过犹不及，追求过度安全而成为发展的绊脚石。安全体系是一个复杂的系统工程，涉及人、技术、操作、管理等要素，单靠任何一个都不可能实现，因此，安全技术与管理机制，安全意识与人才培训等相结合，因势利导，以技术规避风险，以安全保障发展，才是平衡之“道”。

►有的组织选择将安全团队作为应用安全的第一责任人，出现问题后也会将安全团队作为第一问责对象，没有明确开发团队对应用系统的主体安全责任。这种做法要求安全团队以非常有限的人力资源承担了无限责任，容易让开发团队形成依赖感和懈怠感。如果作为应用实际控制人的开发团队不重视应用安全问题的话，安全团队在外围做的事情也只能是隔靴搔痒，效果有限。

►最好最强的安全性是一个什么都不可访问的环境，或者可访问性极其困难且过程繁冗的。客户和网站用户重视安全，但不希望实施重复验证过程呈现繁缛的安全控制，把它想象成一个几乎没有人可以进入的地下银行金库，当人们在进入其中取自己的私人金条时，还需要多个人站在你的旁边监督你的一举一动甚至你的细微动作。安全性和可用性之间的不协调很容易在企业或系统应用之间造成过于复杂和严密的安全性问题，这些可能导致违约和财务损失，甚至是用户流失。这样会使产品研发变得缓慢和繁琐，并导致最终用户使用体验不满意。因此，用户会离开你的页面，到别处搜索甚至卸载你的App。所以平衡安全性和可用性应该是产品设计的关键要求，这一点让产品经理往往不胜烦恼。

如何应对风险？

►安全风险主要来自于人、流程、漏洞和威胁，风险评估的方法主要有定性和定量两种。定性分析是通过权衡不同漏洞和威胁的影响程度，以及发生的可能性来确定出风险的等级，根据风险对业务系统的影响情况，识别需要重点分析的风险以及必要的控制措施和行动。

定量分析是通过对风险指标的量化分析，经过多维度的数据计算后，核算出风险可能导致的经济损失。定量分析需要高质量的数据、明确的业务计划、完善的项目模型和业务的优先级等多个指标支撑。企业在风险评估时需要结合安全现状和业务场景决定需要通过定性或定量对风险进行分析，还是用两者结合的方式。

风险分析后需要针对不同安全级别的风险建立对应的风险控制措施，不是所有的风险都必须处理，不同风险优先级的划分很有必要。风险处置的方式有风险缓解、风险拒绝、风险接受、风险转移。

风险拒绝是针对关键资产和核心业务存在的安全风险，严格执行风险应对措施将风险彻底修复；风险缓解是针对风险等级相对较高，但是安全风险因历史原因无法彻底修复的情况下，需要临时修复方案来进行缓解，为彻底修复风险建立充足的窗口期；风险转移是针对无法应对的潜在安全隐患，有可能对企业造成损失，将风险发生后的损失通过保险的方式进行规避；风险接受是对一些不太重要的风险或者是经过评估后不会对企业造成明显经济损失的风险采取不处理的方式，默认接受风险存在的现状。

►安全是持续变化的。安全领域不存在一劳永逸的技术、设备和方案。从安全诞生之日起，攻击和防御就在不断对抗中螺旋式上升发展，新的攻击手段或安全漏洞被发现后不久，相应的防御手段或安全设备紧随其后被发布出来。没有永远有效的攻击手段，也不存在永远有效的防御措施，二者是互相促进不断发展的辩证关系。

一些安全厂商在向客户推销时，标榜自己的产品无所不能，安装以后可以高枕无忧。然而，安全领域从来没有银弹，安全设备基于黑白名单的特征匹配，如果用固定的防御策略去拦截变化的攻击特征，就犯了刻舟求剑的错误。根据网络安全的变化不断调整安全措施，适应新的网络环境，满足新的网络安全需求，才符合安全的变化之“道”。

►风险接受度是所有风险管理领域教科书强调的一个重点，基于风险评估的风险决策，指导风险控制措施的落地实施，在平衡目标下对风险评估结果，给出风险接受度的相关建议，由业务负责人和公司负责人进行风险决策，是实现风险维度平衡的最佳实践。

风险与组织环境、业务环境、技术体系、业务场景密切相关，风险的评估不仅是传统意义上的漏洞评估、漏洞管理，需要对资产安全属性做相应的梳理，以安全为中心建立资产管理体系。这个资产不仅是传统意义上的硬件、软件资产，还应包含数据、组件、接口等具备漏洞特性的虚拟资产。而在资产生命周期的基础上建立动态自动化的风险评估体系，实现实时风险视图，形成风险接受度建议报告，是建立快速决策沟通机制的良好方法。

风险评估也是被很多安全主管和安全团队忽略掉的实践，并不是不做风险评估，而是以漏洞扫描、安全检测和监测代替了风险评估。威胁的发现、漏洞的评级是风险评估之后安全措施的相关成果，不能替代风险评估，基于威胁和漏洞的决策也不等同于风险接受度决策，而是安全团队内部决策的范围。

过与不及又该如何？

►网络空间安全如何达到一个平衡状态，在组织决策和执行中实现平衡，需要从三个方面综合考虑。不要陷入安全措施底层细节的纠结，而要从安全目标着手，实现安全目标与组织目标和业务目标的有机整合，这个决策层级属于公司管理层和业务管理层对安全团队目标分析的理解和认知。

在安全平衡目标共识的前提下，以安全团队动态安全风险接受度决策建议为基础，组织管理层和业务管理层实现风险接受度的决策，达成风险平衡的共识。有了安全目标和风险接受度的平衡共识，安全主管和安全团队在平行业务部门专业支撑下，主导安全措施的平衡决策。

►针对这些内在的事物，ASPM就是一种可能的解决方案。ASPM是应用安全态势管理（Application Security Posture Management）的简称，是一种让应用系统更加安全且更具有弹性，并且能显著降低业务风险的实践。

ASPM的目标是对生产环境中运行的应用程序其安全风险态势进行全面系统且持续的管理，并且实施更新，这里的安全风险态势包括应用程序的所有服务、第三方依赖库、涉及的API、依赖项、攻击面和敏感数据流等。ASPM允许安全团队在任何时间点快速识别应用程序中存在的最重要的业务关键风险，并确定风险的优先级。ASPM 使用自动化确定业务风险，并且了解外界攻击者是否可以利用该安全风险进而对业务系统造成重大影响。

到目前为止，虽然Gartner等分析公司还没有将 ASPM 确立为一个类别，但是未来的一个趋势，特别是当企业采用持续交付、云和软件 API 来进行业务创新并为客户提供全新体验时，这种需求会更加的迫切。

对于现在公司的安全投入，更多的都是在WAF、设备、盒子等外围设备上，有些会投资SDLC的流程以及零散的AST工具，还有一些会投资SRC等安全运营上，这些很容易导致过度投资、重复建设。但是对于ASPM类似解决方案，投资却是远远不足的，这个是我们未来做安全预算时要去考虑的问题。

ASPM是一个新生的领域，但是值得我们持续跟踪和研究。我们要做到知己，才能知道自己真正的重点在哪里，才能把握过与不及两种状态，不偏不倚，方为中庸之道。

►为了解决这些“过”与“不及”现象引发的问题，笔者建议组织在以下几个方面开展工作：

正式明确安全团队和开发团队的安全责任：组织机构应大力弘扬安全人人有责的风气和文化，安全是安全团队和开发团队共同的责任，特别是在应用安全方面，安全团队与开发团队的人数通常相差悬殊，组织应将开发团队作为对应应用的首要安全责任人。

这个道理是显而易见的，正如小区保安无法帮助业主承担所有的财产风险，特别是房子自身的脆弱性引发的财产风险，业主需要自行安装防护栏和防盗门。安全团队的主要职责是宣传、管控和赋能，协助开发团队开发出更加安全的系统，安全团队应在开发团队中发展懂安全的人员作为业务应用的安全伙伴（通常由应用架构师来承担这一角色）,这一角色负责将安全的要求具体落地到应用的软件需求和设计方案中并对应用的安全性负责。

加强安全支撑能力建设：当组织内的安全团队发展到一定阶段时，为保证各方面安全要求的落地效果，安全团队应提供企业级的方案类和代码类的安全支撑能力，如常用安全设计模式和安全组件等，将公共安全要求转换为开发人员可以理解的开发语言。对于应用级的特色方案设计和代码实现则由应用项目组的安全伙伴负责在应用中落地。安全支撑能力一方面有助于落地各类安全要求，另一方面可以加快业务应用的开发效率，提高安全团队在开发团队中的美誉度。

加强安全产品自主可控力度：一方面针对安全产品之间的重复功能，应从企业级统一的角度确定最合适的承载应用并持续进行开发完善；另一方面加强安全产品在接口方面的标准化设计，方便与内部系统或其他安全产品对接，同时有利于实现安全产品的统一配置管理，保证安全建设和运营效果；再一方面针对安全产品的数据字段进行标准化设计，加强安全数据的分析处理能力，利用大数据技术挖掘更多的攻击信息，提供应用安全水位。

加强安全与应用架构协同：安全的本质是攻防，“井井有条，如数家珍”是安全所需要的，“一夫当关，万夫莫开”是安全所追求的，“车轨共文，一招制胜”也是安全所向往的，架构管控的标准化统一化要求非常有助于安全达成这方面的目标。仍然以日志脱敏为例，如果组织内部可以通过架构的角度统一内部各应用的日志框架，就可以大大减少安全团队和开发团队的开发成本。

更多内容及打卡详情，参见诸子云知识星球。

本月共发出9篇以“过于不及”为主题的专家文章，在此附上链接，供诸位参考。

根据征文活动规则，综合每日打卡、投稿及文章阅读量折合积分后，现将参与者总积分表公示↓

在此恭喜张永宏以95分夺得第一，获得诸子笔会2022的10月月奖，奖金1000元！同时所有发表征文的笔会专家也都将获得200元稿费。