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

渗透技巧 4个月前 admin
218 0 0

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

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

0x1 本周话题TOP4

话题1网商银行在架构里设计了可信架构和纵深防御,想请教下,是实现了白名单的可信吗?

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

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

A:是的,白名单模式,现在已经大范围落地了。最早是从基础设施层和网络访问控制层面做的,今年做了应用运行层面,覆盖率很高了。

Q:正好想问比如进程X这块到哪个粒度合适,带启动参数影响合法业务,不带启动参数又形同摆设。

A:参数要看的,特别是脚本和代码类参数。

Q:应用运行层面的颗粒度,到哪个细节?

A:基于应用切面(类似RASP)控制到类、函数、参数粒度,比如哪些类可以反序列化,哪些类可以执行哪些命令、可以访问哪些文件等。

Q:这个实施中,会遇到哪些比较大的问题?我感觉对于历史包袱比较重的企业,用白名单会导致应用频繁的被干,大量影响业务。

A1:我们现在也在搞,先搞边界。没有资源、样本和经验去对抗0day,只能刀刃向内,用这种方法了。

A2:我个人觉得除非你全自研,标准执行非常好,统一开发框架之类,没有历史包袱,才能这样搞。否则,没法推。

标准化都还是拦路虎的时候,这些工程就不是刀刃向内了,是直接捅进去了。

A3:其实是考验工程能力和治理能力。RASP也是类似问题,在一些标准化比较好的公司推动容易些,对于大部分传统企业来说,都不太好落地。

传统企业,一是标准化不足,二是要开始追赶,这些RASP,什么切面,排不到研发资源投放的优先级上。大领导也是先听业务的。

一大堆不标准的应用,你也不敢拍胸脯说改造不出问题吧,所以你不敢说不影响业务,也不敢拍胸脯说做完之后就一定不出安全问题,也很难量化你阻碍和挡住了多少攻击,减少了多少损失,那么在ROI的表现上,就会显得很难看。当然,如果大老板的意识去到什么很高很高的层次,而资源又很多很多的时候,那做什么都可以。之前有个业务部门,不知道受到什么蛊惑,说要上个什么安全设备和解决方案,我管架构,我说可以,你自己算好ROI就行,后面项目后评价,你的实际数据能支撑你的投入就行。然后业务部门立马缩了,他也不是傻的。

他那套安全设备,那些攻击如果都在前端防火设备被拦了,或者根本就没人有兴趣搞你,结果上线一年没有探测到任何的攻击,怎么办,他怎么解释。虽然我也知道这个逻辑对提高安全水位不太好,但企业就是这么的现实。大领导会觉得你是不是过度投资了。

A5:如果单纯靠攻防演练,互联网公司都很难明确安全投入的ROI是否合理,更别说其它行业了。信息安全防护体系是一个球状立体,单独强调某一点都需要有充分的评估,除非某些方面存在明显的安全短板

想起来小时候参加的交通安全意识培训,看着那种鲜血淋漓、人被压变形的车祸现场确实很震撼。这种偶尔拿出来给领导看下就好,老拿出来就麻木了。

A6:攻防演练,自己要搞到前端的什么都发现不了,只有新建那一套才能发现,那么这么做就有点太刻意了。首先自己团队有没有能力做到这个,如果没有,就要请外面的人,那难道再花一笔钱去证明这个安全平台是有价值的?现在的资源都开始全面投向数据安全这个领域。同样的钱都去投明显的安全短板上了。这个领域,大领导听的懂,也理解。RASP这种偏技术和网络攻防的,大领导听不懂。

A7:数据安全(包括隐私计算)是合规驱动,零信任这种是业界安全技术发展趋势驱动,还有一种就是事件驱动了。技术取向真不是最重要的取向。条条大路通罗马,都是看自己企业的领导风格,企业风险偏好,金融业可能最重要的就是监管风格

虽然我们的愿望是安全和效率双螺旋,互相缠绕上升,但实际上,基于现状很多时候还是安全和效率是个跷跷板,你上我下。风险偏好高且不出名的企业,做跟随就好,等大厂和先驱们把坑趟够了,技术打磨好了,场景培养成熟了,流程顺滑了,再上。

A8:两个不冲突。网商银行等公司,基于自身需求,追求行业领先。其他行业和公司,出于自身实际情况,追求稳定和逐步提升。

不同的机构根据自身的网络安全成熟度以及风险偏好决定。做了并不代表安全就做得好,不做也不一定代表做的不好,适合且与企业业务目标一致

话题2: 爬虫到底是否违法,怎么样算违法,不知道有没有固定说法。

案例:6.1.1 2021 年 6 月 17 日淘宝近 12 亿条用户数据遭泄露 2021 年 6 月 17 日消息,商丘市睢阳区人民法院在裁判文书网,公开了一份刑事判决书,显示一名住在河南商丘市的本科毕业的大学生逯某自 2019 年 11 月 起,对淘宝实施了长达八个月的数据爬取并盗走大量用户数据。在阿里巴巴注意到这一问题前,已经有 1180738048 条用户信息泄露。

A1:在各种判例中,会着重注意一点就是商业目的。去年关于爬虫的判例不少。以至于很多做数据安全的都怕得转业了,招聘也无法明写,也很难找爬虫技能的。

A2:二十年前,大量个人职业者写爬虫,从其他网站爬内容,拼凑自己的网站,引流赚广告费,现在这么搞,大方向上,可能违法了。他没授权你拿,你拿了,然后他举证对他造成了负面影响或损失,法律会支持他。从这个结果来说,爬虫就是不能爬。嗯,只要想告,一告一个准。

补充一点就是,个保法出台后,还要拿用户授权。在前端对个人信息多做数据脱敏和去标识化,爬虫爬的价值就小了,后期还要做拼接难度就大了。

A3:感觉不合理,互联网基础应该是开放共享,有意识放到网上供人查阅的,只要没有声明限制访问方式,个人觉得就应该默认为允许。所以爬虫应该合法。另外一个层面,不管数据的来源是什么,泄露他人隐私信息是违法的。所以,爬虫应该无罪。判刑的名义应该是信息泄露相关罪名。

A4:重点是1. 数据是否为公开数据 2.是否明确版权禁止转载。3. 是否有明显的反爬虫技术手段与相关TOS。如果突破反爬虫那肯定是不对了。

A5:海淀区去年几个爬虫的判例,主要看
  • 爬虫是否用于商业用途,衍生出研判是否存在非法行为和恶意用途。目前主要体现在非法获取信息系统和不正当竞争这俩罪名上。
  • 是否有绕过和对抗反爬能力,衍生出是否存在入侵行为,体现在非法入侵和非法破坏两个罪名上。
  • 看数据是否涉及到授权和数据敏感性上,衍生研判数据量级和敏感度,体现在非法获取公民个人信息罪上。实际上会有多个情况的叠加。对于反爬虫来说,如果选择司法介入,需要留有确实证据,如换算的直接资损或间接自损(商业模式上的换算一般不太认同), 二是对对方本身目的的初步研判用于立案。

A6:爬虫几乎全都可以扣上消耗服务器资源、突破反爬限制、未经授权爬用户数据的帽子

A7:很多网站流量就是爬虫爬出来的流量,不遵守Robots协议,而且robots其实很多地方不认…主要原因是目前我国司法尚未承认Robots协议单独能够成为具有法律约束力的合同。君子协议而已。换着UA,换着IP池就可以绕过大部分反爬。

话题3:数据泄露的应急预案,数据泄露如果是拖库撞库引发的,第一时间该如何处置?

第一步肯定是防止风险持续做止血,第二步分析影响面找到降危手段缓解后续风险,第三步溯源并找有关部门打击

至于预案,起码要体现四个部
  • 一是通报预警,谁领导,小组里可能有技术,可能有pr,可能有合规,可能有负责数据治理的;
  • 二是影响评估,通过什么手段发现的,内部还是外部,已知泄露了多少,是否全了,并且持续报告问题原因,举一反三;
  • 三是应急处置,是否能采取隔离措施防止影响扩大,包括pr的应急;
  • 四是总结报告,复盘整改,上报给谁,谁牵头上报监管,报告哪些监管,是否公告,标准分级是什么,时限多少。

至于系统怎么监测,通过流量还是数据库,怎么用技术分析风险,在预案里是最不重要的,因为你不可能想全,有了预案,另行去做技术落地都可以,但预案要兜底,发生了能处置,把授权决策提前定下来,别出了事没人做主

话题4web应用架构设计中前后台分离,一般我们会把WLC/Jboss/IIS等放在DMZ,数据库放在更可信的DBzone,但是现在一些设计往往把Nginx放在DMZ而把WLC/Jboss等放在更可信的APPzone再由App调DBzone的DBserver,DMZ的Nginx一般只配置简单的反向代理。这样可能会出现的问题是应用有问题直接打到Appzone内部。如何设计更合理,目前大家的best practise是什么样的?

A1:两个方案就是多了个区域而已,其实考验的是东西向和南北向的隔离是否做得够好。隔离做不好,结果都一样。没太大区别。

A2:纵向ng→app→db架构,个人觉得没问题的:ng可以很好隔离app服务器的暴露问题,攻击落到app区,这个风险缓释措施是app区的横向隔离。而且本来就需要ng做反向代理,可以防止app区服务器应用系统过度暴露

Q:纠结在传统意义的dmz以及防火墙异构设置,如果ng穿透那就直接进内墙了,这是新旧交替改造时经常遇到的问题。随着技术的革新,传统意义的dmz逐渐在失去。

A3:边界防火墙异构个人觉得意义不大,增加风险点。敞开大门做生意,肯定要进来的,不纠结dmz区名词。而且我理解还是存在的,只不过叫“暴露面”了,你问题里的appzone就是暴露面。

暴露面的层次:第一层:ip和端口层面;第二层:应用url层面;第三层面:应用功能层面。对应收敛暴露面,第一层收敛:防火墙acl;第二层收敛:ng;第三层收敛:应用框架。

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

A4:无论是叫DMZ或者是暴露面,安全的角度看就是要在当你的web/接口站点被黑后尽可能小的影响其他的系统。不同公司执行程度不同,我们是禁止Dmz的ng直接转发进内网,用户浏览器的流量要在DMZ落地。如果你们认为appzone更适合承接这个暴露面的风险也是可以的

具体实践上,我们是和开发pk,要求把业务包部署到dmz。这过程也非常难,有时也被挑战,说你看看啥啥公司,人家就可以ng穿透进内网,所以,这东西,目前没啥标准,都是安全和业务的平衡。

0x2 本周精粹

网络安全审查办法

《网络安全审查办法》已经2021年11月16日国家互联网信息办公室2021年第20次室务会议审议通过,并经国家发展和改革委员会、工业和信息化部、公安部、国家安全部、财政部、商务部、中国人民银行、国家市场监督管理总局、国家广播电视总局、中国证券监督管理委员会、国家保密局、国家密码管理局同意,现予公布,自2022年2月15日起施行。

一个安全从业人员的前半生(上学篇)


我的大学生活,既不精彩,我的大学成绩,也不耀眼。我只是茫茫人海,千千万万普通人中一员,为了美好生活和家人的希望,认真生活和不断奔跑。虽然我过早的接受了生活的重担,没有享受到很多同龄人的快乐,但我也收获了生存的本领。任何事务都是两面的,失去一些的同时也会收获另外一些东西,天行健,君子以自强不息。

时间不语,却回答了所有问题。

「君哥的体历」文章目录(更新至2022年1月8日)

七大主题,点击文章标题即可跳转原文

  • 君哥的企业安全建设实践
  • 群大咖分享
  • 群实录荟萃
  • 群周报
  • 群活动暨其他
  • 招聘
  • 君哥的生活体历

0x3 2022年第1周运营数据

金融业企业安全建设实践群 | 第129期
本周群里共有 104 位群友参与讨论,群发言率为24.30%,群发言消息数为 499 条,人均发言数为 4.79 条。

企业安全建设实践群 | 第54期
本周群里共有 42 位群友参与讨论,群发言率为9.07%,群发言消息数为 96 条,人均发言数为 2.28 条。

0x4 群友分享

【安全资讯】

《网络安全审查办法》答记者问

中国银保监会印发信息科技外包风险监管办法

盘点 | 一文速览2021全年国内网络安全领域重要政策

中国人民银行印发《金融科技发展规划(2022-2025年)》

证监会发布《证券期货业移动互联网应用程序安全检测规范》金融行业标准

【安全运营】

浅谈数据安全运营能力建设

实录 | 廖威:安全意识培训千人千面

独立 SOAR 的终结?Google以5亿美元收购以色列网络安全初创公司Siemplify

【年终总结】

我在美团的八年

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

往期群周报:

办公网出向流量SSL ForwardProxy解密方案,一次dnslog误判事件暨企业安全建设预算调研报告分析 | 总第128周

SOC接入哪些日志比较有用?内网传输是否一定需要开启SSL?企业内网访问微信服务,如何知道微信验证的IP段? | 总第127周

log4j2漏洞修复方案探讨,安全平行切面与现在的纵深防御体系区别,微信公众号、小程序等安全资产维护和管理机制 | 总第126周

如何进群?

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

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

原文始发于微信公众号(君哥的体历):网商银行安全可信纵深防御框架实践落地,爬虫违法与否,数据泄露应急预案编制及Web应用网络安全架构设计探讨 | 总第129周

相关文章

暂无评论

暂无评论...