员工被公司盗号邮箱钓鱼后的个人经济损失处理、员工行为风险预警合法性暨交易数据加密存储解决方案探讨 | 总第132周

admin 2022年2月7日00:33:43评论465 views字数 4753阅读15分50秒阅读模式



员工被公司盗号邮箱钓鱼后的个人经济损失处理、员工行为风险预警合法性暨交易数据加密存储解决方案探讨 | 总第132周


员工被公司盗号邮箱钓鱼后的个人经济损失处理、员工行为风险预警合法性暨交易数据加密存储解决方案探讨 | 总第132周


0x1 本周话题TOP3


话题1:各位大佬,员工因为使用公司邮箱收到被盗号的公司邮箱账号发的钓鱼邮件,扫描了钓鱼邮件的二维码而导致个人经济损失。这种个人经济损失如何处理?

员工被公司盗号邮箱钓鱼后的个人经济损失处理、员工行为风险预警合法性暨交易数据加密存储解决方案探讨 | 总第132周

温馨提醒:此钓鱼邮件已多家单位收到,建议各位同仁警示内部员工,也可仿造来一波全员测试,加强春节前后及冬奥会期间的安全意识宣贯。

A1:当天先应急处置
  • 全员发邮件通知避免范围扩大;

  • 有邮件网关尝试把邮件拦截,删除;

  • 有防火墙或者上网行为拦截扫描二维码跳转的链接地址;

  • 如果是对个人转账联系客服看能否申诉退回


A2:类似的应急处理措施在收到员工反馈后立马就做了,还是有员工中招了,而且中招员工反馈“一扫钱就没了”,所以上面犯罪网站打码了。


A3:这个听着有点猛,扫码就没,除非是类似个人的收款二维码,扫描没看清楚指纹就确认支付了。很多人会把“接到诈骗电话后去atm上按照谎称为检验的指导给对方打款”也说成钱直接没了,自己对关键操作没留意都忽略了。


其实还是人的贪念,“可以领补贴”。稍有不慎,就掉入“黑客挖好的坑里面”。


至于员工关心的个人经济损失,其想问经济责任吧,这个交给警察界定就行,公司讲法理应该没有赔偿的法律责任,被盗的那个员工违反了公司规定没保护好账号,但也没有赔偿责任,盗号的人才要承担法律责任,不过还是尽心帮他走走流程抓下罪犯挽回损失比较好,毕竟从情感来说是工作事宜被盗的。话又说回来和公司有关的其实只是公司账号增加可信度,他做了什么操作导致扣款很重要,要溯源,个人没有警惕心那在外头也一样被骗的


A4:这个去年已经有不少公司中招了,是以人社补贴的名义,今年改了名又来了。


员工被公司盗号邮箱钓鱼后的个人经济损失处理、员工行为风险预警合法性暨交易数据加密存储解决方案探讨 | 总第132周


员工被公司盗号邮箱钓鱼后的个人经济损失处理、员工行为风险预警合法性暨交易数据加密存储解决方案探讨 | 总第132周


上面截图里,领取补贴要填银行卡号很正常,但这个骗术的一个明显特点是,需要员工填写银行卡的“可用额度”。这是所有正规网站都不会存在的选项,但骗子前期铺垫那么多,就是为了准确知道能从受骗者那里骗到多少钱。很多人急于领取补贴基本不假思索就填了

套路都是一样的个人意识不够,最主要的贪想了解一下后来这个走司法程序了么?


A5:有经济损失的员工在意识到被骗后立即就报警了,警察在跟进调查,同时事发当天做了如下应急措施:
  • 通知全员所收的是钓鱼邮件;
  • 在邮箱后台把钓鱼邮件删除;
  • 邮箱账号登录地址限制为内网和VPN方式;
  • 通讯录限制为只可查看本部门账号。

话题2:大家有做员工行为风险预警吗?通过收集公开的舆情、诉讼、工商、行政外罚等信息,结合个人征信、银行账户状态对员工进行综合分析,输出风险报告,主要目的是预防员工因8小时外的个人问题,对企业实施极端行为造成损失。

A1:这个太全了,个人征信、银行账户,这些数据一般企业能拿到吗,即使拿到了也侵犯了员工个人隐私权益,我们有和员工签署《员工个人信息收集告知同意书》,但是也仅限工作范畴。

A2:明显超出了工作所必需的个人信息收集范围,涉嫌侵犯隐私和违规监控,分析的结果也不能拿来作为处分员工的依据。

监控员工稳定性、员工离职倾向这类动作可以,但需要考虑合法、正当、必要性,不仅仅是授权就可以了。即使授权,员工也是被迫的,还能反告公司网络安全法、数据安全法和个人信息保护法都发布实施很久了,个人信息处理需满足以下条款:

第五条 处理个人信息应当遵循合法、正当、必要和诚信原则,不得通过误导、欺诈、胁迫等方式处理个人信息。
第六条 处理个人信息应当具有明确、合理的目的,并应当与处理目的直接相关,采取对个人权益影响最小的方式。收集个人信息,应当限于实现处理目的的最小范围,不得过度收集个人信息。
第七条 处理个人信息应当遵循公开、透明原则,公开个人信息处理规则,明示处理的目的、方式和范围。

A3:防止删库跑路不是这么做的,人(恶意)只是一个维度,还有主机(可靠性)、系统(批量功能可用性)首先确定风险大盘,定义极端行为的影响高低和成熟度;再分类,内部系统、数据库、运维管理,挨个评估恢复、容灾、日志审计能力等,形成多种解决方案(自动发现、审批、离职权限收敛、演练)、覆盖了之后评估风险是否削减。

A4:为安全是一种动态安全,不可控的,只能从软硬件、制度等控制,来降低行为安全的风险。不要以网络安全的名义为虎作伥...上面提了,人只是一个元素,有时候流程、系统设计更重要,大家上班不是为了搞破坏,关注系统容灾备份和人文关怀吧,以现在的变更管理水平,解决无意造成的故障的优先级大于恶意行为的优先级。而如果要对员工安全意识画像,我觉得可以从下面几个方面着手
  • 培训试题,针对岗位、细化题目维度

  • UEBA

真要防止删库,靠安全画像肯定是不够的,关键还是技术管控,比如权限管理、恶意指令禁止执行、重要操作双人复核、数据备份管理。

话题3:向各位专家请教一下关于交易数据加密存储的问题:一是关于交易数据加密存储,有没有成熟的解决方案,既能保障数据的保密性,又能保障交易性能不受影响;二是交易数据加密存储后,其他使用交易数据的关联系统如何正常使用加密后的交易数据。 


注:此处的交易数据在JRT 0197-2020《金融数据安全 数据安全分级指南》中有定义和要求。


A1:上述指南中,交易数据基本上等于很多数据。此类型很多,为了合规,一般做透明加密,可以用公司资源试试数据库透明加密。不过建议还是追问一层,为什么要加密存储,根据期望交付成果的不同,数据库透明加密有可能会成为业务无感知成本最低方案或者是最自欺欺人的方案。


我们碰到的检查目标是:查dba、sa这些非业务人员能不能看见全部敏感数据,结果就是要字段加密,所以这个你们还真得确认下期望交付结果。


A2:三级系统就需要加密,数据库透明加密是方案的一种吧,我理解可能有三个层面的加密,自顶向下依次是:

  • 应用系统实现

  • 数据库实现

  • 存储实现

其中,应用系统实现既麻烦,又极有可能不满足性能要求,而且这层可能过不了检,因为检查预期就是看落地是否加密,而存储最简单,成本也低。不过,目前我们采用的存储不支持加密存储。


A3:交易数据加密建议先以个人信息为主,采用应用层对称加密存储,可以用sdk方式;其他应用使用先申请解密后再用自己的密钥加密在加密存储,如果有开发支持可以支持基于权限的加密方案。


Q:不知道应用层是否有实现的案例架构咋样?秘钥放在哪里?对性能影响大吗目前正在寻求解决方案中,今年必须解决的问题哪怕是评估不通过也行


A4:应用层加密,要有完备的数据字典,明确定义的数据库字段含义,才能有针对性加密。交易数据这么多的字段,所有入库数据都加密,也不现实。

A5:确实不可能所有数据都能这么干,得针对特定场景,其中数据资产肯定是梳理的越清晰越好,没必要存的数据当然是不存为好,但是这个工作很难做吧。

至于秘钥存在kmskms的工程成熟度很高,稳定性都得到了验证性,但如果交易数据太多,几百上千的字段,kms就有点存不来了。

性能这事,怎么说呢,10万tps,我们用x86集群也扛得住,而且瓶颈不是加密机,加密机能承受几十万,但也不是那么简单,没法简单地给个结论。总之,最不依赖业务的一定是透明加密,我们这么干也是为了满足上面说的IT审计以及一系列法规要求,就是要让自己人看不见明文。

A6:可以考虑数据库统一做一个代理,类似于数据库防火墙,设置加密策略,针对特定数据库,字段按照策略进行不同类型的加密和解密。

Q:有数据库层面加密的解决方案吗?是否是严重依赖数据库本身的功能?

A7:数据库层面依赖于数据库的支持了,而且离应用越远,越容易出问题,因为你不知道应用要咋用。而且数据库层面做跟应用层面自己改造,一样会涉及让应用梳理数据链路和场景,实际成本未减少的…单纯考虑性能,或者旁路方式来做,都不是最主要的。

A8:有加密网关的产品,可以看看是不是符合需求。性能方面如果产品有问题,也可以考虑自己来做,覆盖需要加密的数据库即可,与数据库本身没有太多的关联,一般是通过解析通信协议来实现的。一般情况下,加密机不是瓶颈所在。如果要实现国密改造要求,这样来做也是比较好的一种实现方案,应用自行加密也可以,不过那就是推送应用改造的问题了。

A9:建议把密钥管理和加密分开。尤其是应用层的加密,把密钥给到应用,他自己去做,而不是在密钥管理系统上管理对哪些字段加密。我觉得要离应用越近越好,而不是越远越好,且离密钥管理系统越远越好。

以KMS为例,它可以是一个负责dar enckms,里面自然还是要有appprofile的,但是是不是要细化到维护加密那个字段,我自己认为不需要在这里维护,太多责任。

0x2 本周精粹

聊聊API安全的重要性及治理思路
在互联网的世界里,“安全”和“开放”是一个永恒的话题,但“开放创新”的前提必然是“安全可控”,也就是说没有安全的API,创新是不可能的。

0x3 2022年第4周运营数据

金融业企业安全建设实践群 | 第132期
本周群里共有 127 位群友参与讨论,群发言率为29.74%,群发言消息数为 556 条,人均发言数为 4.38 条。

企业安全建设实践群 | 第57期
本周群里共有 70 位群友参与讨论,群发言率为15.12%,群发言消息数为 325 条,人均发言数为 4.64 条。

0x4 群友分享

【漏洞情报】

关于网传VueJS漏洞浅析

利用SourceMap还原前端代码

Linux Polkit权限提升漏洞风险提示

漏洞预警:Linux Polkit权限提升漏洞 CVE-2021-4034
Are there any mitigations for this vulnerability? If no patches are available for your operating system, you can remove the SUID-bit from pkexec as a temporary mitigation; for example: # chmod 0755 /usr/bin/pkexec
漏洞验证github上已有POC,https://github.com/berdav/CVE-2021-4034。

【安全资讯】

大厂监控风云

痛点与热点|2022年中国网络安全从业及认证调研报告发布

重磅丨深圳出台数据条例执法细则:数据交易、算法歧视等在列

CCSIP 2021中国网络安全产业全景图(第三版)正式发布 | FreeBuf咨询

“一行两会”联合发布《金融机构客户尽职调查和客户身份资料及交易记录保存管理办法》(附全文+答记者问)

中央广播电视总台2022年3·15晚会主题发布

https://vod-finance.cctv.cn/cctv/cctvh5/cctv2/2021/share/index.html?pageId=app://ARTI1642904608920936#/detail?link=ARTI1642904608920936

员工被公司盗号邮箱钓鱼后的个人经济损失处理、员工行为风险预警合法性暨交易数据加密存储解决方案探讨 | 总第132周


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

往期群周报:

红蓝对抗服务之攻击队约束条款、业务首次上云避坑讨论暨sudo账户管理问题 | 总第131周

从CMDB到SCMDB,安全资产管理的实践探讨以及向上管理艺术之如何有效争取资源 | 总第130周

网商银行安全可信纵深防御框架实践落地,爬虫违法与否,数据泄露应急预案编制及Web应用网络安全架构设计探讨 | 总第129周

如何进群?

如何下载群周报完整版?
请见下图:

员工被公司盗号邮箱钓鱼后的个人经济损失处理、员工行为风险预警合法性暨交易数据加密存储解决方案探讨 | 总第132周

原文始发于微信公众号(君哥的体历):员工被公司盗号邮箱钓鱼后的个人经济损失处理、员工行为风险预警合法性暨交易数据加密存储解决方案探讨 | 总第132周

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2022年2月7日00:33:43
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   员工被公司盗号邮箱钓鱼后的个人经济损失处理、员工行为风险预警合法性暨交易数据加密存储解决方案探讨 | 总第132周http://cn-sec.com/archives/766525.html

发表评论

匿名网友 填写信息