主动防御策略结合隐私保护与运维风险管理，构建多方位安全体系，提升数据安全与合规性。｜总第284周

0x1本周话题

话题一：在甲方安全里，主动防御一般涵盖哪些措施？

A1:网安将反制定为违规行为了，目前就只做了情报、蜜罐、资产监测之类的，还有SOAR、资产安全监控、研发过程安全管理、攻防演练也可以算，提前封堵风险，偏主动防御。

A2:安全意识培训是不是也算主动防御的一种？另外，K01那种也可以说是联防联控。

A3:说到了K01，请问下大家把K01是什么定位，阻断开了么？

A4:看下来，只要是事前做的事情，都算作主动防御了。这个范围确实有点大，事前是不是可以再分层，特别主动，一般主动，一般不主动。

A5:可以分角度理解，一个是技术角度，比如哪些技术是主动防御，哪些是被动防御；另一个是管理角度，就是在攻击或者安全事件发生前采取的措施都算主动防御。

A6:个人见解：

• 安全管理方面：组织保障，先要有人有预算。

• 安全制度建立与落实，风险评估，主动依法合规。

• 技术方面就多了，安全是设计出来的，要有安全架构融入到软件开发和供应商管理。上安全设备和提软件开发验收要求，安全意识培训。外部安全情报转化为内部检测规则。

A7:如果忽略厂商包装，从学术源头讲，比如我弄个防火墙，只开443，你其它的进不来都拦住了，这就是被动防御，你扫我445我还监控感知响应，还管你是谁、在干嘛，就是主动防御/积极防御，换成别的节点也一样。

A8:我这么理解：头痛医头、脚痛医脚：被动防御。防患于未然：主动防御。

A9:威胁狩猎是个比较典型的场景，它是事后的，但是active defense，主动分析有没有遗漏的威胁。

A10:威胁狩猎和应急响应的区别是什么？

A12:所以威胁狩猎这种主动防御虽然跟事前事后没关系，但还是在做防患于未然的事儿。这个视角，挺有说服力。安全是个动态、持续的过程，这次的事后，是下次的事前。

话题二：大佬们，如果有人在生产服务器配置代理上网，这种一般怎么处置？

A1:先看看是否正常需求代理吧，有些服务确实是有代理的，但是你说的代理上网，那就是有问题。

A2:从描述看来像是服务器挂代理自己pc上网。如果不是正常，先看看日志什么的有没有。开除也得看员工管理规定吧，讲证据。

A3:有一帮卧龙开发，在已有访问权限的服务器上配置了代理，让没有网络访问权限的服务器通过这个代理访问外部的系统，我在配置漏扫任务的时候，漏扫在扫描时通过这个代理扫到了外部的系统，然后这个外部的系统在把我们的出口IP封掉了，导致部分服务不可用。

A4:开发能直接搞生产服务器配置，这个流程管控是不是也有问题。

A5:尺度领导把握，但是你不去搞就是害你自己和其他安全和运维的同事。先和开发沟通，然后看他们的态度是否拉上更上面得领导解决，他们愿意配合的话之后也要和领导汇报下，之后给it部门全员发送邮件强调纪律。

不要自己底下去跟研发聊，这种问题你去私下聊跟包庇有啥区别，为啥要因为别人犯傻牵连自己进去。

A6:该开处罚单开处罚单，最后真该开除就开除，你只能说你这次是漏扫扫到了，那要是非漏扫期间，出了问题，到时候走的是你。

A7:那你就要开始准备全部排查了，再讲人情这种涉及到数据安全的问题，你看一把手愿不愿意因为人情背这口锅啊，说是违规外联，万一数据从这泄露了谁能扛的起这口锅。

给领导发个邮件，你已经揭示了这个风险，履职留痕。如果你的领导不处置，那是他的问题。

A8:这种先搞清楚，是不是本来业务就需要的，然后为了方便没考虑到安全问题，自己搭代理走流量出去了，如果是这样可以先警告，然后给他们解决这个问题，以后就不会出现了

A9:就通过统一反向代理或者api网关对外业务访问这个，是业务问题，但是因为漏扫导致出口被封，那是漏扫的锅，要是扫到的是监管，那就是真 G 了。

A10:我觉的这肯定不是漏扫的锅，研发都没告知这个是向外通的，安全咋知道呢？反而漏扫立功了，要是不扫出去被封了感知到，这个大口子哪里去知道，这种就是典型的盲区。

A11:制度里面有没有明确要求，培训里面有没有讲清楚，问责不是目的，解决问题才是目的，如果没考虑过这种情况，没有制度要求过，那就摸清楚业务需求更新制度要求，并且宣发清楚。

A12:如果漏扫是例行的，他们突然搭建的系统导致产生这个问题还好说。如果是第一次漏扫，业务跑了很久了，那这锅是谁的不好说。

A13:安全不是这么兜底的，要看制度是怎么定义安全的角色，如果这么要求了，那就要求安全扩编。正常的这种变更是要知会安全进行评审。

A14:有一说一，开发为啥能够登录到生产服务器上？

A15:这个代理是在反向代理区域，以前漏扫不扫这个区域。

A16:这不就是非法外联么，先通报个典型，再完善制度和技术吧。怎么处置是领导需要考虑的事吧，至少要通报典型+宣导，完善制度和流程。

话题三：咨询大家个问题，对于安全发现风险，项目组/运维方整改比较抵触，出现整改不及时等问题，在管理层面有哪些好的建议思路？

A1:找他们部门负责人先沟通，如果他们也抵触，你就上升到技术条线领导，甚至cto。

A2:可能沟通的层级不够，意识不到重要性，逐级上升去聊。

A3:安全团队没有价值，过往合作过程中都是考虑自己团队利益居多，没有共赢。

A4:安全视角下：

• 风险影响分析到位。

• 清晰传达至业务（有决策权层级）。

• 形成共识后盖戳。

• 建立兜底能力和晾晒机制。

业务视角下：

“反复打扰、事后找麻烦、零零散散、风险不大、资源投入多、收益不高”，再想想策略。

A5:先从公司战略管理层面达成一致，你才好推动工作，也就是一把手责任制，包括成立安全委员会，把各个部门的大佬纳入进来，和kpi挂钩，今年不做，明年看到绩效自然就做了。从业务优先到安全优先要经过2-5年的一个过程。

A6:是的，需要找到部门之间共同的利益点，弥合分歧，流程按照发现风险，评估风险，接受或整改风险，不要安全一言堂，客观公正的同步风险，最佳的是建立一个顶层设计框架来规范风险的评级和整改标准。

缺乏标准，风险评级不准确，随便发现一个风险都要立即整改，这对业务来说也是不可接受的。缺乏标准，风险评级不准确，随便发现一个风险都要立即整改，这对业务来说也是不可接受的。

A7:首先还是看业务目前处于什么阶段，再看安全能做啥帮助业务，风险可以接受或者兜底降级，不是都需要马上修复的。

A8:了解他们抵触的原因，从原因分析对策，但见得多的不外乎：增加工作量，增加稳定运行的不确定因素。

A9:并且设计了个原则，坚守底线，合理有效处置风险。我的一些愚见：

• 网数委汇报纳入风险整改内容。

• 部门领导沟通，开发/运维kpi补充漏洞整改指标。

• 发布漏洞管理规范(含漏洞优先级)，和开发/运维打磨。

• 项目技术任务包含漏洞处置要求。

• 组织培训加强宣贯。

由于微信修改了推送规则，需读者经常留言或点“在看”“点赞”，否则会逐渐收不到推送！如果你还想看到我们的推送，请点赞收藏周报，将【君哥的体历】加为星标或每次看完后点击一下页面下端的“在看”“点赞”。

如何进群？