0x1本周话题

话题一：大佬们，请教下APP端的报文传输安全业内一般是怎么做防御的，目前已知HTTPS、SSL Pinning，请问还有什么防御手段吗？

A1：代理vpn的检测，各种hook框架的检测，完整性检测。或者ua。

Q：有单独对报文body加密的实践么？这种单独对报文加密的方法推荐么？

A2：传输安全包括防重放这种吗？一般来说端对端证书也可以，单独加密行是行但是流量大了还是有点吃资源的。

A3：开发工作量大，加解密要时延。如果解密是在业务端的话，还会带来流量监测致盲的问题。这个问题一般怎么解决呢；是多划一个南北向的区域还是有啥其他好办法呢。

A4：不要过分依赖客户端安全，服务端就不要信任客户端的请求。

A5：阿里是用了一个霸下平台，mtop第一关网关上把能校验的和可以解密的全都在这里解决掉，尽可能保证进入内网的流量是干净可靠的。

A6：目测在内网前端搞个可以解密流量的网关是较好的方案，就是有研发成本。

A7：数据走标准协议，用https加密就好了，如果自己数据前端自定义加密，只是给自己加重负担。如果前端被逆向爆破，整个前端加密是透明的。

A8：是本质上只是增加攻击成本，所以也是想了解下业内是否有必要搞这一层。

A9：采用非对称加密，没法爆破吧。

A10：也可以走MTLS做双向证书校验。请求报文加密和加签还是必要的，敏感信息ssl加密基础上需要做二次加密，可以缓解接口被刷风险，增强接口保密性和完整性。

A11：用https的TLS 1.2以上的证书就很安全了。保护接口靠认证，不是靠二次加密。很多端是H5页面，所以将端看成普通网站前端就好了。

话题二：想咨询下各位大佬，一般应用系统版本迭代时，每次上线前都要做安全测试及漏扫吗？还是说看版本号，看开发人员是否申请，等别的情况？我们目前定的是新建系统或者系统架构做调整的已有系统，感觉这样的条件每年做不了几次安全测试及漏扫……上面现在让我们统一做标准，咋定义呢？

A1：看具体迭代内容、类型评估是否需要做，不能一刀切。调个参数改个配置肯定不用做。

A2：底线：新建、重大(比如原本对内改成对外)，也就是你的现状，把高危风险把住，同时也是合规底线。

中间态：制定标准，有引入新功能送检漏扫及渗透测试，将决定权交给开发，并培训代码走查的安全要求，codereview都是各部门做的。

标准化：所有代码发布串IAST，所有预发环境串DAST，识别到引入新功能或新组件的触发漏扫及自动化渗透测试，所需要投入的人力也是越来越大的。

重点：制定的流程，如果开发有另一条路上线，就会绕过，所以要抓一到多个卡点，并且集成到开发测试流程里，做好事前约定，以书写规范为例，开发领域约定很重要，适当将一些标准的判断执行交给开发部门中的复核人员。

A3：但实际情况：

• 一是没有自动化的流程来做漏扫及渗透，开发和安全是两个部门，肯定需要人工流程介入。
• 二是开发阶段安全比较薄弱，我其实是不太放心的。
• 三是开发有时候想申请，运维这边还得审核下是否要给他做安全检测。

综合看来标准可能能定，但是一个灵活的，除了已有的2条，增加一条类似距离上一次上线前渗透时间久（不少于1年）、新功能开发较多、属于互联网系统等漏洞管理部门及建设部门沟通认定需要开展安全检测情况的。

A4：如果要甩锅建议每次都搞一遍。到底检测是锅还是不检测是锅？每个人的想法看起来似乎不一致。

A5：我们现在是安全卡点在开发流程中：

• 项目立项或大迭代，技术评审要叫上安全参与，提出安全要求（主要是SDL安全基线的内容再强调下，同时也评估下应用架构，评估是否间接影响网络架构的安全性）。
• 对于Web类的系统是在开发完成后必须人工介入安全测试，非Web类的满足最低要求4A即可，不强制人员安全检测。
• 上线部署，如果是Web系统或面向互联网开放的http 类API，要接入WAF。
• 为了防止绕过上线，安全在上线流程的工单一个节点。因人力有限，内部目前是简化版的SDL流程。此外：1、每个Q团队内部也会进行一次交叉安全测试，主要针对互联网的资产； 2、每年至少请外部专业的安全团队（看HVV排名来合作）进行一次互联网资产渗透； 3、积极参与网络安全三部门的HVV活动，防守、攻击两个角色都有。

A6：看起来已经很落地很务实了，从这些基础工作和领导安全意识中，最能看出安全水平。

A7：有些系统开发商都倒闭了，或者没有给维保费用，出漏洞都找不到人。

A8：主要是看看别人家咋分工的，还有漏洞评估这个事情客观来讲建设者来负责，还是漏洞管理人员，还是两者一起？我感觉客观讲应该一起。但是实际工作中，建设者说是管理人员（负责出漏洞报告、定级），管理人员感觉应该是建设者。

A9：安全负责督办，提修复建议；上线前是开发负责，上线后应用层漏洞开发负责修，系统层漏洞系统管理员牵头定修复方案。这个关乎漏洞修复原则。我们定的是：谁接近，谁负责。接近就是说，这个漏洞所属资产的管理责任方，谁更接近就谁负责修复。

Q：比如一个常见的场景：建设者开发的系统，漏洞管理人员发现了漏洞，谁来评估呢？评估什么？

A10：安全评估实际风险等级，确定要不要修，督办风险处置；研发确定怎么修，能不能修，要不要缓释，还是躺平。

A11：躺平不能是研发确定了，躺平得能承担责任的人来确定。所以就在评估工作里写清楚各方职责吧，卡壳的时候也找过商务出面沟通，厂商态度会好些。

话题三：群里问问各位大佬，linux主机防护都咋弄的？

A1：商业产品啊，上不了商业产品有开发整一套也行。

A2：HIDS还是蛮有用的，服务器量不大，采买比自己整成本低。

A3：采买主要面对历史存量巨大的版本差异。有开源的，有精力预算又不够就直接上。

Q：遇到供应商效率及其低下由什么好的办法吗？

A4：开源的问题比较多啊，还是用商业产品来定制开发吧。

A5：第一是外包科技天然有能力丧失的风险，从管理上就要有这块的规划应对，哪些是依赖厂商，哪些是自己掌控，产品选型是托管还是接口化，供应商人员规模、服务地点，这是源头。

第二是签约时要考虑尾款和履约要求，拿一些东西压供应商，对他们评价，甚至扣款，从法律上支持，事先明确规则。

第三是也要考虑供应商的实际情况，比如并非合同内容那也情有可原，利润低尾款少，供应商的发展方向是否契合，最好还是能共赢。

A6：如果规模不是特别大，可以以试用的名义，一年换一个，先撑过三年再说。别超过一年，各厂商应该都能忍。在试用期间，再去寻找价值，寻机采购。如果一直没发现什么有价值的事情，也能证明确实没必要买。

很多现在买产品的差不多都是要测试1～2年左右；达到标准以后，再立项开干哈，因为很多产品都达不到甲方的需求，需要不断开发完善才行。

A7：没自己的核心开发人员，用开源很难搞。到时候出问题，跟业务冲突，头很大。

A8：我记得原来深圳有家公司在做SOC时就说了，要测试使用三年没有问题以后，再买；好像很多厂商都被吓退了。最后好像是某某信同意了这个要求哈。全面使用3年，然后再花钱买第4～6年的。

A9：这种真是饮鸩止渴的模式。乙方赚不到钱，短期回不了利，自然没有钱去打磨产品的能力，甲方试用3年，能得到什么？浪费3年的机会和时间。也不能怪用户这么苛刻，主要还是太多产品太差了，不然也不至于用户都快失去信心了。

A10：甲方被送了3年的白嫖，然后自以为占了便宜，指使乙方按甲方的功能修改，定制，结果最终甲方被乙方的产品高度定制化，也许只是UI，OA上面的所谓打通，但核心能力一点没变，最终投标的时候，自然这家乙方是中标方，所谓的双赢。

但后续维护甚至无法使用标准升级框架，这样的系统，到底是谁被谁白嫖，谁被谁绑定了？哪有那么多人力物力试用三年生产数据，神都知道不可能，就是为了白嫖而已，没什么可说的。

A11：qxx的入网认证模块，没见他们有迭代升级的好用点，甲方试用也得乙方厂商研发有热情跟进。把长期试用当营销噱头是远远不够的。

太多厂商的产品经理，做的东西没有灵魂，浑浑噩噩的，不知所以然的在做产品。除了抄袭，就是所谓的“用户需求”。

A12：好的厂家是教用户怎么实现业务目标，而不是客户牵着厂家走，不懂产品的产品经理是比较常见的。准确是说甲方有权拍板的那些人合不合适，毕竟拍板和部署实施管理试用的，屁股位置不同，认知差异也比较大。

A13：小CS这点做得不错，就抄了CS，怎么的，这个就是需要的产品。就能帮到甲方。不过现在市场趋向成熟，难了。试用三年，你就离不开他了，应该是打的这个算盘。投进去的成本，最后都会收回来。

A14：上面已经说了，1年，3年的定制化，你看其他竞品是怎么都看不顺眼的。甲方不可能再选择其他的。美其名曰共赢。1年也好，3年也罢，生产数据，说来这么简单随意迁移？

A15：最近接触的安全产品大部分都在堆功能，把以前的功能整合在一起，通过不同的组合重新起名字封装后拿出来卖。

A16：咱们自己也是用户，虽然管不了别人，但实际的技术和产品骗不了人，试用没问题，真有预算就试用，然后也确实要试用多家，不涉及什么迁移问题。真要试用多家，应该一份数据，多发，不然不好对比。

A17：现在很多安全产品都在往综合化做，客户要什么就加什么进去，好不好用是一回事，然后又背负历史技术债问题，里面一堆代码，最后表现出来就是一个巨大的客户端，动辄几百 m 的升级包。内存资源占用动不动2个 g 以上，客观上为终端设备硬件升级助力。最后等你用熟悉了，再推荐一个所谓的新框架版本，号称能解决一些问题。

A18：市场不认小而美，要增长，就只能发展其它领域。卖贵，客户不接受；卖多，难。卖更多种类，这个故事好讲，也能给盈利不增长或不盈利找借口。

A19：其实我们linux上装hids纯粹是为了合规，所以核心需求就是能设置各种策略符合等保要求，然后不要影响业务，所以厂家给我个空壳也行。hids不管在合规还是入侵发现还是蛮有用的。

Q：恶意代码检测软件+hids+自动化管理客户端+日志采集客户端+远程桌面管理，这些是服务器主机必须安装的基础项目么？不算应用。

A20：我觉得不是，有些不是安全需求。桌面管理就堡垒机，日志采集是日志采集，自动化管理类似于ansible，这些都是运维需求。虽然不论谁，包括hids，只要有agent的人都能做，但它一般来说不是项目范围。

如果出于项目集成的考虑，也不是不能合并，但肯定不是必选项，相反，为了保业务连续性划清责任推动项目成功，往往会阉割掉自己给服务器下脚本发指令的能力。

0x2 群友分享

【安全资讯】

网络安全产业：真正的狼，是云厂商

为什么DataDog能吃几个、夹几个、看几个？

银行业漏洞治理实践与展望--漏洞治理的道与术

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

【金融业企业安全建设实践群】和【企业安全建设实践群】每周讨论的精华话题会同步在本公众号推送（每周）。根据话题整理的群周报完整版——每个话题甲方朋友们的展开讨论内容——每周会上传知识星球，方便大家查阅。

如何进群？