内部如何防止终端中毒？各家强密码具体要求是什么？法律角度下，不同方式加密传输手机号的区别是什么？【 总第262周】
文化
科技
2024-09-26 17:00
甘肃
话题一：市场上是否有成熟产品，能识别并展示一家单位的网络安全风险？Q：现在市场上有没有成熟的产品，可以把一家单位的网络安全风险识别并展示出来？风险方面有缺失的，各位也请帮忙补充补充。（我想到的风险有：漏洞、异常端口开放、异常业务开放、经常曝漏洞的中间件、开源组件使用、缺少必要的安全防护措施、代码泄露、敏感信息泄露、供应链风险等等。）A1：看这些功能，比较像CAASM。现在金融行业，供给面管理，落地情况如何？A2：这些都是外部暴露的风险，如果要评估一家公司的安全状态，还可以学供应链安全管理的一些思路，看内部安全和过程安全，比如有没有专门设置安全组织、内部内部运转机制。A3：您说的是完整的风险评估。我们主要是想从外部视角，来建立一家单位的风险视图。A4：你只要有这些风险探针，能把数据收上来，剩下的买个 BI 工具，自己搞两个开发做报表就行了，难的是怎么采集这些风险数据。风险感知做不全、不准、不及时，最后就是个态势感知大屏，形象工程给领导和参观人员炫的。A5：我理解，安全运营，不就是得把所有的风险汇总梳理出来，然后挨个解决吗？所以，大家应该已经有落地的，市场上应该有很多这样的产品才对。A6：正经这么多年用过的最有效的监控大屏，反而是做减法的，正常状态没有信息，只要出现信息就要立即处理，把它清屏。- 外部看就是：资产威胁暴露的，像：ip资产，端口，指纹，漏洞，风险，情报等，可以参考常见的 攻击面管理软件。
- 内部看就是：通过探针，内部资产sbom，各类安全工具等发现的风险。比如：os，二三方组建漏洞，安全设备以及覆盖率，通用安全运营的情况，漏洞管理，安全告警，事件等等。这类不同公司情况不一样，都没有一个产品解决。主要看你们的目标，业务需求是什么。
A8：从业内实践来看，攻击面管理作为威胁识别的第一个产出物，至关重要，如果攻击面遗漏了，后续再强的措施也没覆盖，所以这个问题提得很好。不管是20年前的还是最新的书籍都会提到安全资产管理，我还记得君哥以前在谈这个问题的时候，特别提到了公众号这类易被忽视的资产（攻击面），是我当时没考虑到的，所以对当时一个脑图印象特别深，不仅有域名、ip、端口、api、中间件、供应链、漏洞这些传统的资产，也有账号、数据、特权等易被忽视的资产。这些内容在公众号、书里我看都有。在我自己的实践中，确实对安全态势进行感知是企业需求，是必要的，是我们的价值输出，对传统资产最常见的就是定期主动扫描。例如地址池中多出来一个活的ip，端口，接口，指纹，都是要响应的，同时需要与之配套的管理要求和卡点，尽量在卡点处做到白名单的更新。除了主动方式外，被动监测也是有效的比对方式作为补充。另外还有一些内容比如仿冒网站、暗网情报、泄露爬取的感知，中间需要夹一层定期人工研判，也是监控的范围。做到这，基本上攻击面管理就有个形了。接下来我认为主要就靠打攻防演练，因为自己做威胁识别，经验再丰富也毕竟是推演，没有经过实战检验，打一打，可能就不会发现，有的人在外面认证了公司账号，有团队买了个企微saas服务……这些都可能构成攻击面，需要通过实战来迭代。金融为什么难打，我觉得很关键的差别就是重视结果、管理手段能落实、业务能支持投入，最终实现了攻击面小，才不好打，换言之，这个现状都是打出来的。所以，我的结论也出来了：固然有产品能帮助我们省去一些重复劳动，尤其是互联网监测的部分用采购的方式社会总成本更低，但想要用一个产品来绘制自己企业的全部风险地图还是不现实，产品必须做通用才有社会效益，才能活下去，这是规律，甲方只能在通用的基础上叠加自己的个性，做一些开发整合也许效果更好。话题二：大家公司针对强密码的具体要求是什么？例如：1、大写字母、小写字母、数字、特殊字符：这个大家是四选三还是都满足？ 2、密码不能使用近五个密码变更周期内相同的密码？A1：再加一项，任何系统初始密码必需改，不然有些服务默认的密码虽然是强密码，但是都是一样的。1是windows的，默认多数都是按这个来。两高一弱对弱口令规则有说明，可以作为依据。A2：建议再补充附加规则，比如Aa111111..满足第一条复杂度要求，但是还是很容易爆破。Q：大写字母、小写字母、数字、特殊字符都满足的话，有要求的出处不？四选三，其实现在有很多弱密码符合复杂度要求，比如键盘顺序之类的，这种有没有规则能禁止掉？- 密码不能包含连续4位及以上的数字或字母，如“12345”。
- 密码至少包含以下四类字符中的三类：大写字母、小写字母、数字、特殊字符。
- 密码不能包含用户名、工号、xxx、admin、password等易被猜解字符组合。
A4：1qaz2wsx 这样也不行。要求强密码，还不能重复过去几次用过的，有人因为记不住就把密码记到便签或记事本里，这又引入新的风险。
A5：密码复杂度制度好写，但是做自动检测和禁止确实很难，无论是开发人员的意识还是算法本身。现在弱口令仍然最大的安全风险。A6：是的，我们现在是从统一身份认证处来维护规则，设置的时候检测。多因子也可以达到目的。银行的取款和查询密码也就6个数字，更多还是要靠其他手段来保证。银行也没要求用户用强密码，多因子认证就可以了。A7：人脸都只能当辅助认证的。业务场景和用户体验一定要综合考虑的，安全可别太极端。现在如果是金融产品，不安全，只有密码认证，我会非常担心它安全不安全，安全现在是必选项。微信，支付宝每次启动直接用，不需要额外的让用户感知到的身份认证步骤，这不就挺好的嘛。安全做到用户无感知。A8：微信底层和支付宝做得很安全的，反正大家信任。所以国家如果推统一身份认证，比如使用微信和支付宝这样的，更方便。现在银行也是支持刷脸就可以了。A9：现在有些还会要求不连键，避免键盘连键字典爆破。这个是需要安全基础的，后端需要投入很多基础能力才行。不是一般企业能满足的，然后妥协下就增加用户挡板。A10：支持SSO认证就可以了，很成熟的技术。SSO可以让支持弱密码排出， 验证码，以及加入短信验证。再不济可以绑定常用设备等方式吧。并且SSO依赖统一认证平台，不用收集过多用户信息。A11：密码策略也就是基础，参考Apple策略强度就差不多了，再强的会影响体验。密码策略就是包含特殊字符，数字，大小写，就没有什么了。而且你看现在的Wordlist，同时满足这个规则的一样是弱密码，因为在列表里面了。话题三：请教一个问题，A是2C企业，有用户手机号，A与B合作，需要传输手机号，那么： 1、Hash（手机号） 2、加密（手机号）。Q：从技术实务角度看，没大区别。从法律角度看，有何区别？A1：这个感觉直接咨询公司法务部门更权威一些。现在很多不是直接传输的，尤其金融的，好像是直接加密碰撞相关的手机号。取决手机号是否需要解密，如果不解密，哈希就够了。A2：hash不属于加密，如果有心也有算力，可以把所有号段的手机号码进行hash计算，形成字典，然后把截获/泄露的hash后的手机号进去碰撞就能还原了，所以hash无法保证数据的机密性，只能用于验证数据的完整性和一致性。A3：Hash使用SHA256，加Salt很难还原，碰撞也很难。加密意味着可以解密，不一样。法律上看hash也是可以通过碰撞还原的。A4：都需要证明，加密需要证明你的密钥保存与交换的可靠性，外挂KMS这种，Hash要证明你的hash算法的不可逆性。A5：HASH算法是标准的，已经得到证明的。难道还有人自创算法？这个无关技术了，比如你泄露了一千万条数据，里面有姓名、假名手机号、假名银行卡号，这个假名是对称还是哈希都是一样的，不会因为你说是哈希就认为不可能对客户造成不良影响。如果我知道你的算法和你的salt，知道你的算法和密钥，条件是一样的。就算说每一个客户都是一个单独密钥，成本高得多，也一样，都是假名，不是匿名。A6：算法可以了解，Salt就难了。主要是hash有撞库的风险，所以欧洲GDPR 美国FTC 中国个保法 都不认为无盐的hash是属于法律意义上的匿名化数据。A7：Salt是必须的，算法一般都用SHA256或者SHA512。salt是为了验证口令而做的。这做了salt,传输给对方就是无意义字段，这没法合作的。A8：法务意见是，由于A给了B key，B有能力逆向，所以加密不是去标识化的个人信息，风险比给Hash高。A9：这种就是对称加密。但如果你们法务说，hash的话b没能力，你就用hash。A10：所以，我提了技术角度无差异。法律实务怎么看？Hash确实有个借口，名义上不可逆，穷举是技术手段。hash到达一定量的时候，啥加密都有可能破。A11：直接逆不可逆，手机由于是固定位数，就是空间换时间了，如果不是手机号还有的说，手机号范围太窄了。不是技术问题，是法律实务问题。技术大家都了解效果的。A12：法律实务问法务，真的，这是背责问题，从我们法务，以及我受到的认证培训，你这个场景非常常见，对方不借助额外手段，就能定位到具体个人，不属于去标识化。Q：先确定是防B，还是防通信被第三方窃听？如是前者，加盐哈希没意义吧，对方有盐有彩虹表怎么都可以逆向 B自身，有没有这些用户的手机号？是为了匹配用户，还是为了获取手机号明文？如果B没有手机号数据，也不想让B知道，传手机号字段的意义是什么？A13：他不防b，我理解反而需要b返回一些风控信息之类的。该按假名化处理的，结果按去标识化/匿名化处理了，法务背就听法务的，换做是我我不提意见，我顶多在中间加些手段，比如加一层标记化，投50％的毒等等。A14：换个说法，这里就是目标是，A要跟B交互，要传手机号，哪个法律风险低？A16：我要尽的义务是：即使b被脱裤了，密文密钥都拿走了，我也有手段保护客户隐私。Q：搞清楚业务的需求才是重要的，比如B需要知道手机号码吗？还是只需要一个代号就可以了？A17：对，加一层标记化的意思就是，给代号。如果你认定它是去标识的、匿名的，根本不用做这些，匿名是不可还原的。如果不需要还原，也不想做标识，直接建立Hash和编号的对应表给对方就可以了，这样别人怎么撞库都没有用。A18：所以这个东西不是有专业的产品去解决吗？联邦计算，不就是专门做这个的吗？还有同态加密。A19：你说的这些都是将手机号作为标签运算了，实际业务上需要原始手机号发短信之类的。只有加密通道传输就可以了，可靠传输。但是这个涉及个人隐私，应该要告知用户。Q：如果是这个业务，能不能做到只给手机号，不给用户名，把它做成单要素？A20：我看也有法律界意见说，单因素的手机号在无外界能力情况下，无法对应的个人，理论上不应算作个人信息。确实有一定道理，但一般还是参考金标按照个人信息管吧。A21：这块我们咨询过监管，仅单要素是个人信息但不算个人敏感信息。转换的界限很模糊，躺在一堆数字里就是无意义数字，有一个刚买房人群的标签就是敏感信息了，判定不是那么机械的。话题四：请教下各位，在各种免杀技术的情况下，内部如何防止终端中毒？A1：白名单，执行程序白名单匹配hash之类的，操作起来会很累。各种白名单，与互联网隔离的终端中毒概率已经很低了。A2：白名单是事中，不上网是事后。都有效，两者结合起来威力更大，但是没法避免各种安全介质的拷入。A4：可以弄个情报之类的。在已经不上网的情况下，中毒的危害，集中于勒索和蠕虫。远控已经可控了，然后再扎口拷入，程序白名单，风险小很多了。A5：USB禁了，禁外网、程序白名单、USB白名单。三大杀器解决99%内网问题。A6：没法禁，总有业务需要拷入。其实除了勒索危害，和少部分漏网之鱼请求到三方专线网络，实际危害不大。但是经常看到外联实在没办法。A7：那就是中毒了嘛，扫扫雷，拿结果约束业务。程序白名单你们实施了？A8：很难，做不到，量太大，光收集都是个头疼的事情。软件每更新一次，hash匹配就得重来一次。拷贝机有了，专门的摆渡系统，系统自带查杀，但对免杀无济于事。A9：不上网已经不太存在所谓的面杀病毒了。不上网+程序白名单，免杀咋进来。可执行的话他又不在白名单，也不会让他执行。也就是说：不上网，免杀进来也没法外联，这个时候只剩下蠕虫勒索之类的了。A10：在没有联网的情况下，通过其他介质感染的病毒没有高级免杀能力，是没有多 stage 病毒的可能的，所以不存在免杀能力的了。银行的话，管控应该足够到位吧，推一推应该还是可以搞搞的吧？A11：白名单困难，但是隔离是必须的。无法通过 c2下发的病毒危害性相对可控，当然存在某些顽固蠕虫利用内网漏洞的可能，不过杀软毕竟不是吃干饭的。A12：免杀是为了next stage做准备和先决条件，如果已经禁用了互联网，没有外联的可能性，免杀的意义基本上可以忽略了。A14：存在这种可能，但这种一次性的病毒成功率极低，除非是裸机。没有绝对的安全。A15：AV+EDR 异构是你的解决办法，如果这都不能缓解焦虑那就真的只有白名单了。不异构都在抱怨说一到点就卡，再异构那就要疯。或者升级换内存，换 SSd。Q：那延伸一下，大家怎么确定程序加白的？特别是操作系统，经常一个什么配置就多一个进程了。edr拉清单出来，怎么筛选哪些是正常的，看签名？A16：先装一台干净的，全加白，然后再叠合法软件，当然这台干净的里面不能有啥微软虚拟机云盘啥的，得大致看下，不能联网，它不是主要风险了。A17：但是不同配置下可能不一样，比如刚刚的rdl服务。做得好一点分组，也可以全局加白，毕竟，你要防的是病毒，而不是授权。A18：主要是请教看看难度有多大，再综合考虑优先级。A19：点数越多越难，版本越多越难。但是在银行，不稀奇。你已经禁止上网了，还有中毒的，领导不接受这风险，那咱要给解决方案，要么事前管入口，入口管不住只能事中了。A20：这个在macfee里面也有标准机。我们除了没有8和8.1，其他基本各种大小版本都有。A21：可以考虑先从入口扎试试，同时推一下一道防线责任，一道责任下去了，能通报他们了，可以结合着搞事中了，别乱来。如果一道责任压实下去了，可能在入口管也就能管住了，服务和管理，最好别扎在一起，至少名义上职责分开。A22：避不开这个问题，“最小所需”的必要性上，是做服务，还是做管理。A23：一步步来，先上网白名单，然后慢慢的禁外网，然后程序白名单，上网白名单搞出来，基本上本地av+edr的卡顿就减少很多，卡顿多无非是外联进来的东西多了，触发扫描多了。A24：外网和usb管理是有的，传统三板斧就差白名单了。白名单对黑加白手法，lolbin也是缺乏对抗效果段的。现在还有powershell无文件落地的，所以只能说尽量。没有外联 c2，这种 ps 无文件可能性不存在。话题五：请教各位，统一的日志审计平台，哪家做的好一点？（XX易的SIEM平台太贵了。）Q：有没有请大数据分析的厂家来做日志收集解析的案例？A1：开源 elk + flink；免费elk 付费splunk。A2：有国产化的要求，elk，splunk都不太敢用了。A3：某朝某达不也做这个的？或者通过soc平台做统一日志审计呢？A4：一开始也是想通过SOC接入，但是SOC要接入这些日志，增加的主机和存储资源和日志解析告警的功能报价更贵。想着看看能不能找做大数据分析的公司看看能不能做，他们对字段解析，存储，查询这些经验更丰富点。Q：你们soc厂商的对系统的日志解析和告警做的怎么样？A5：一般让厂商写规则，但自己也支持一个可视化的字段解析，常见的问题都不大的。解析日志或者kafka，实现都很简单，无非有的厂商适配做的多，自带现成规则就多，有的少一点。不存在经验丰富的问题，主要还是厂商服务跟得上就行。A6：看过某盟、某服的日志审计平台，只有在主机装了插件的才能解析。syslog的都不能解析，要自己写规则。主机上再装插件，那不是嫌自己头上的锅不够吗？A7：一般不是rsyslog配一下，发到日志服务器就行了吗？A8：不行，解析不了。需要适配。那就是需要单独适配规则。A9：肯定需要规则解析，只是大多数厂家对常见的基本都支持。有 ai ，帮忙写解析语句还是挺方便的。看了上面那两家的，说是都支持。但是现场看都是需要装控件才支持。syslog的要自己写规则。A10：我们soc这边不需要装agent，发到服务器这边就行。A11：那感觉他们也只是做了存储和简单查询。如果后期要做告警的话，不做日志解析做不出来的。国内的太依赖厂商去做适配个写规则，适配一个数据源能搞好几天，结构化的还好，我碰到好多非结构化的有些就抓瞎或直接不支持。A12：应用系统的日志解析就很麻烦，应用系统如果是自研的话，可以统一要求字段和格式。
由于微信修改了推送规则，需读者经常留言或点“在看”“点赞”，否则会逐渐收不到推送！如果你还想看到我们的推送，请点赞收藏周报，将【君哥的体历】加为星标或每次看完后点击一下页面下端的“在看”“点赞”。【金融业企业安全建设实践群】和【企业安全建设实践群】每周讨论的精华话题会同步在本公众号推送（每周）。根据话题整理的群周报完整版——每个话题甲方朋友们的展开讨论内容——每周会上传知识星球，方便大家查阅。
如何进群？
