夜雨聆风交流群里有群友分享了一个案例，自家公司的内部员工访问了仿冒网站下载了以为是正常的办公软件，运行该软件后最终导致中了木马，期间该员工的朋友圈不受控制发布了相关灰产推广信息。
这是一个很明显且相对常见的现实存在的终端安全现状，我刚好看到截图，立马回复了一个结论，这个恶意文件大概率属于“银狐”，事实证明是对的。
基于对终端安全的兴趣，私下里沟通了一下。我把视角从“检测”转向“体系”后给对方建议了一些可以利用“管控”思维来避免此类风险的思路，后续回复是所在企业已经把管控思维给现实落地了，太好了，说明我的认知与想法基本上是对的。
本次中招的案例属于BYOD（自有设备），该设备的安全控制策略与企业内部的终端设备不在同一个基线。这其实又回到了对资产进行分级分类的治理范畴，有时候换位思考一下也能理解企业内部非安全从业人员的员工属性，并不是每个人都具备极高的安全风险意识。安全是纯成本部门，定位就是赋能或者促进业务的，如果影响业务连续性了，安全就可以靠后了。有时候困扰企业安全（特指终端安全）的因素也不仅仅是所谓的与国外优秀安全产品的技术代差，也与无法避免的现实【性能损耗】以及【业务摩擦】和安全价值之间能否达成平衡的困境，也可以称之为安全与业务平衡的艺术。
后续了解到的情况是甲方企业对于安全的预算投入每年高达几千万，钱是花出去了，但是当前是不直接产生“盈利”的，安全价值如何衡量呢？因投资安全造成的回报能否比较好的覆盖确实是非常重要的考量。如果说这笔预算依赖于乙方供应商确实是可以造成成本下降，财务报告会很好看，所以换一个角度去考虑这件事还真是不一样，确确实实对业务优先这个原则有了比较大的体会。
上述是一些简短的背景信息，基于此，我展开思考与推演。最近在重新思考办公环境下的终端安全问题时，又重新回到了一个比较现实的话题，如果只是为了防御如今大量存在的钓鱼木马、仿冒软件下载、办公环境恶意程序执行，那么真正有效的方式到底是什么？🤔这些年行业里讨论了很多关于AI检测、行为分析、EDR对抗、内存检测、云沙箱、威胁情报等话题，以及现在火热的大模型赋能安全，但现实里最常见的入侵链，其实依然还是用户下载 → 用户执行 → 程序联网 → 控制上线。然后进一步窃取敏感信息或者劫持办公IM、财务欺诈，最终可能会发生内网横向。看多了也就见怪不怪了，确确实实没咋变过路径与套路。
基于我先前文章提到的约束>检测的思维进行展开，结合零信任理念（切记不是买一个产品就是零信任落地到位了•ᴗ•💧），所以有时候会发现，现在很多办公环境面临的问题，并不是“检测不到”，技术相对是够的，并没有特别难啃的难题，况且还有很多甲方企业选择自己研发定制终端安全产品，而是系统本身默认允许执行，Windows系统的自由度太高啦，导致攻击面极多，自由等于体验好等于安全隐患极大。
一、从 AppLocker 开始重新思考
既然是管控思维，结合零信任理念就不得不提到 Windows 的自有安全机制了，最近看到一些关于 AppLocker 的内容后，又重新思考了一下这类方案在现实企业里的价值，合理性如何？以及性价比和隐藏的坑有哪些？适合哪类企业体量等等。
如果从非常纯粹的角度来看正常办公人员，其实并不需要每天安装新的程序。尤其财务、HR、行政、运营、普通办公人员，其日常软件其实长期固定。那么理论上完全可以对新增程序执行增加约束。例如Downloads、Temp、AppData目录默认禁止执行。或者新增程序需要二次确认甚至审批（一定要考虑运维成本和用户体验）。
从现实效果来看，这类方式对于现在大量活跃的钓鱼木马，其实会有非常明显的效果。因为绝大部分黑灰产程序，本质上还是依赖“用户主动执行”。而不是高复杂度漏洞利用。
以上是思路推演过程，本质是回归问题本质，避免陷于乙方产品套路之中，乙方产品最大的受益者还是背后的乙方，但国外的安全产品更贵🥲。
二、但现实企业环境又会出现新的问题
没有一种方案是只有好的没有坏的，🙁真正开始思考落地时，很快又会发现另一面。例如开发需要本地编译、运维需要脚本、老旧OA需要插件、某些国产软件兼容性差以及各部门存在“祖传工具”。
于是默认拒绝执行虽然安全收益很高，但业务摩擦也会迅速增加。再加上AppLocker策略维护、Hash更新、Publisher兼容、DLL规则误伤以及白名单管理。长期下来，运维成本其实并不低。尤其大型企业环境中安全很多时候并不是“能不能做”，例如如果安全策略影响了业务连续性或者生产效率，那么就是安全给业务拖后腿了😱(┬＿┬)，长期以往安全部门必然在企业内部陷入信任危机或困境。而是“是否能长期运营”。否则最后通常都会逐渐变成加白、放通与特判，然后边界再次被打开。
三、终端安全开始从“检测”转向“约束”
终端安全一定要关注微软等产品的思维以及发展，难道还有哪家企业有微软这样的先天优势吗？例如CrowdStrike SentinelOne 以及 MDE ，后面再继续看如今微软这几年的方向，会发现一个比较明显的变化。例如WDAC、Smart App Control、HVCI、Reputation-based Trust、VBS。其核心思想其实都越来越偏向减少“自由执行”。因为现代攻击已经越来越不像传统病毒。大量攻击链开始依赖PowerShell、LOLBIN、内存执行、签名程序以及云下发载荷，于是单纯依赖检测会越来越困难。因为“正常行为”与“恶意行为”的边界已经开始越来越模糊。最终检测体系会不断增加Hook、增加行为分析、增加内核逻辑、增加AI关联，然后终端越来越重。
现实里很多企业真正面临的问题，反而开始变成安全与性能、业务之间的冲突。
四、一些比较现实的思考
回归问题本质，抓住核心矛盾。将防御思维逐步转向零信任理念上，现在再回头看，可能会越来越觉得终端安全真正重要的，并不是“检测能力越来越强”。而是是否能合理减少攻击面的执行空间，让攻击者利用成本越来越高。例如Downloads禁止执行、Temp禁止执行、Office子进程限制、PowerShell限制以及高风险LOLBIN限制。这些东西从技术上看并不“炫”，都是非常常见的，但现实效果却可能比很多复杂检测更直接。因为如今大量办公环境安全问题，本质上还是用户能够自由执行未知代码。所以现在越来越能理解为什么微软这些年会越来越强调Trusted Execution、Application Control、Code Integrity，因为相比无限制地做“猫鼠游戏”。约束，本身可能才更接近终端安全的本质。
写到这里想起来了前几年工作的时候遇到的一个安全防御思路，简单粗暴直接，终端安全产品直接把 PowerShell 执行权限给禁用了，然后就是🌚安全效果还挺好，很多勒索或流行木马确确实实受限了。代价就是用户体验极差，可能经常会被业务投诉，最后肯定得改掉。
我碰巧那时候查询了微软的官方文档，他们提到了这个情况，说明他们在企业安全内部实践中也遇到了这个坑，所以微软文档里建议不能直接禁用PowerShell，而是采用其他策略防御。
企业安全的一点展望，如何在预算限制、业务摩擦、运维成本、安全效果、价值认定、协作信任里找到平衡点确实很难。
附录如下
Microsoft AppLocker 是 Windows 内置的应用程序白名单机制，通过精确控制允许运行的应用程序，实现“默认拒绝”的零信任安全管控。它能有效防止恶意软件执行及员工运行未经授权的软件。
企业规模较大或处于高安全要求的行业，建议使用更现代的 Windows Defender 应用程序控制 (WDAC)，这是微软在零信任架构下推荐的更高级白名单解决方案。
