ChatGPT网安应用前景如何?企业移动应用安全怎么做 | FB甲方群话题讨论
2023-4-14 19:3:34 Author: FreeBuf(查看原文) 阅读量:15 收藏

各位 Buffer 晚上好,FreeBuf 甲方群话题讨论第211期来了!FB甲方社群不定期围绕安全热点事件、前沿技术、运营体系建设等话题展开讨论,Kiki 群助手每周整理精华、干货讨论内容,为您提供一手价值信息。

重要提示:本期话题讨论中有社群成员“偷懒”,利用ChatGPT作答,你能看出来吗?欢迎在文末留言,我们将随机挑选三位猜中的读者送出“神秘奖品”~(留言格式:话题序号+回答序号,例如:话题一A3)

注:上期精彩内容请点击 实施零信任的困难和挑战;安全顶层设计思路探讨

本期话题抢先看

1.现阶段以ChatGPT为代表的人工智能模型对网络安全起到的辅助作用究竟有多大?

2. 企业在管理或者使用移动应用程序时应该注意哪些安全问题?

3. 企业未来是否会像管理办公电脑一样管理移动设备?

4. 为什么会说高位端口(大于1024以上的端口)不安全?

 话题一 

现阶段以ChatGPT为代表的人工智能模型对网络安全起到的辅助作用有多大?有没有实际的应用场景,比如漏洞扫描、威胁情报?

A1:

FreeBuf有文章说到过ChatGPT的一些应用:《攻防潜力股:ChatGPT的实习报告》

https://www.freebuf.com/news/362480.html

A2:

上午也刚看到一篇这方面的文章:

A3:

啥时候能有高效的私有AI感觉才好落地AI的安全实践,这接OpenAI的接口搞东西对国企来说行不通。

A4:

所以写基础文档还可以,但是需要公司内的数据信息的情况下,还是建议手动补全,国企肯定不能用。

A5:

一般我觉得最大的帮助就是提供框架、模板。帮写报告模板、做总结、写演讲稿等。实际应用的话场景也挺多,不过对于数据脱敏的要求也高,直接用起来运营成本也很大。

像漏扫、情报等也得考虑这些。总体而言我觉得纯ChatGPT对于公共涉密不强的场景会应用多一些。其他的情况会按需使用,自研模型另当别论,上面图中那些领域都可以尝试。

A6:

大家有没有考虑过企业内部开发使用chatgpt带来的数据泄露风险?

A7:

这个确实考虑到,所以内部也得有相应的说明,哪些场景可以用,哪些不能用。

A8:

我最近也在想,大家有啥好方法,主要是审计方法,禁用是禁不住了。

 话题二

移动应用程序可以加快企业内信息传递、业务流程审批的效率,但也带来了很多安全风险。大家能否分享一下企业在管理或者使用移动应用程序时应该注意哪些安全问题?

A1:

移动应用程序应该完整检查上线后才能投入使用,同时既然企业内部使用,不应该投放在应用市场上,应放在企业内进行下载安装,减少暴露面。

A2:

企业信息数据安全事故中有50%是因为内部员工而起,约有20%的安全事故被认为是内幕者恶意行为,比如说员工可能从泄露的数据信息中获利。员工的主要泄密途径除了拍照泄漏、存储在手机中外泄外,还有离职员工拷贝企业重要信息。

A3:

在对移动应用程序进行测试时应尽量使用测试数据而不是使用真实数据,测试版本的数据库应与真实环境隔离开来。

A4:

1、首要的是数据泄露问题,需要考虑限制APP数据范围,限制截屏录屏,数据远程擦除;


2、其次对于BYOD,需要考虑隐私合规,进行必要的合规检测,避免合规问题;


3、最后就是APP自身安全性,上线前安检扫描等等。

A5:

先说可能面临的安全问题:


1.移动应用程序可能存在违规收集、使用、共享、转让或公开披露用户个人信息的行为,给用户隐私和利益带来潜在风险和危害,也可能导致企业违反相关法律法规,受到监管部门的处罚或用户的投诉;


2.移动应用程序可能存在数据跨境传输的情况,需要遵守目的地国家或地区的数据保护法律法规,同时也要保证数据传输的安全性,防止数据被截取、篡改或泄露;


3.移动应用程序可能存在数据明文传输的情况,导致个人信息、敏感信息、商业秘密等数据在网络传输过程中被窃取或泄露;


4.移动应用程序可能存在逆向分析、盗版篡改、插入不良信息、运行干扰破坏等风险,影响移动应用程序的正常功能和性能,损害企业的品牌形象和商业利益;


5.移动应用程序可能存在漏洞或缺陷,导致移动应用程序被黑客攻击或利用,造成数据泄露、系统崩溃、恶意代码植入等后果。

而为了解决这些安全问题,企业可以采取以下措施:


1.建立并完善移动应用程序的个人信息保护制度和流程,遵循最小必要原则收集、使用、共享、转让或公开披露用户个人信息,明确告知用户个人信息的收集目的、方式和范围,并征得用户同意;


2.在进行数据跨境传输时,遵守目的地国家或地区的数据保护法律法规,采取加密、匿名化等技术措施保障数据传输的安全性,并与境外数据接收方签订相关协议,约定数据保护责任和义务;


3.在进行数据传输时,采用HTTPS等安全协议和标准,对数据进行加密处理,防止数据在网络传输过程中被窃取或泄露;


4.对移动应用程序进行安全加固处理,防止移动应用程序被逆向分析、盗版篡改、插入不良信息、运行干扰破坏等风险;


5.对移动应用程序进行安全测试和审计,及时发现并修复漏洞或缺陷,防止移动应用程序被黑客攻击或利用;


6.申请并通过移动应用程序安全认证,获得权威合规证明和竞争优势。

A6:

分公司资产和个人资产吧,不同类别,管理的手段可能不太一样,在监管合规前提下,一防外部威胁攻击,二防内部信息泄露,具体的技术和管理手段,看你愿意付出多少钱了。

A7:

数据泄露:移动应用程序可能会处理企业内部的敏感信息,如客户数据、业务流程、财务信息等。因此,必须确保应用程序在传输和存储数据时使用安全的加密方法,以防止数据泄露。


身份认证与授权:移动应用程序应该有强大的身份认证和授权机制,确保只有授权的用户能够访问应用程序和其中的功能。采用多因素身份认证,如指纹、面部识别、二步验证等可以提高应用程序的安全性。


恶意软件和病毒:移动应用程序可能会面临恶意软件和病毒的威胁,这可能导致数据丢失、系统崩溃等安全问题。因此,应采用安全的开发实践,包括定期更新应用程序和操作系统,使用数字证书和代码签名等方式来防止恶意软件的侵入。


数据备份与恢复:移动应用程序中的数据应该定期进行备份,并确保能够进行有效的恢复。这可以帮助应对数据丢失、系统故障等突发情况,并保护企业的数据安全。


社交工程攻击:社交工程攻击是一种通过欺骗用户获取敏感信息的方式,例如通过钓鱼、假冒身份等方式。企业应提供培训和教育,教导员工识别和防范社交工程攻击,避免在移动应用程序中泄露敏感信息。


设备管理:企业应该采用设备管理策略,包括远程锁定、擦除、设备密码等方式来保护移动设备的安全。如果员工使用个人设备访问企业应用程序,应规定安全策略,并确保设备处于最新的安全状态。

权限控制:移动应用程序应该实施严格的权限控制,确保用户只能访问他们所需的功能和数据。对于敏感操作和数据,应实施细粒度的权限管理,仅授权给需要的用户。


更新和漏洞修复:企业应及时跟踪移动应用程序的更新和漏洞修复,并在漏洞修复发布后尽快更新应用程序,以防止已知漏洞被利用。

安全审计与监控:企业应该建立安全审计和监控机制,定期检查移动应用程序的安全配置、日志记录和事件监控。这样可以及时检测和应对潜在的安全威胁,并确保移动应用程序在持续运行中保持安全状态。


员工教育和安全意识培训:企业应定期对员工进行安全教育和安全意识培训,提高员工对移动应用程序安全的认识和警惕性。员工应该了解如何正确使用移动应用程序,如何处理敏感信息,以及应对安全事件的应急措施。


第三方应用程序安全:
如果企业使用第三方应用程序或服务,应仔细评估其安全性,并确保其符合企业的安全要求。应定期审查和监控第三方应用程序的安全性,并与供应商建立安全合作关系。


合规和法律要求:企业在使用移动应用程序时应遵守相关法律法规和合规要求,如数据隐私法律、个人信息保护法规等。确保移动应用程序的设计和使用符合当地法律法规,并对可能的合规风险进行评估和管理。


总的来说,企业在管理或使用移动应用程序时应重视数据安全、身份认证与授权、恶意软件防护、数据备份与恢复、社交工程攻击防范、设备管理、权限控制、更新与漏洞修复、安全审计与监控、员工教育和安全意识培训、第三方应用程序安全以及合规和法律要求等一系列安全问题,以确保企业的移动应用程序在保护敏感信息和业务流程的同时,能够有效防范安全威胁和风险。

A8:

某书旗舰版可以限制文件保存本地、加密存储。但是想进一步的限制截图、禁止复制外发可能就得上MDM了,这块权限蛮大的。这块是 DLP的安全问题。

Q:移动应用有互联网使用场景,如何管理相关的业务暴漏面减少被攻击的风险?

A9:

在开发过程中,引入预审批机制,对于敏感API和隐私信息的使用提前进行报备。在上线前做动态检测和静态扫描。动态检测覆盖绝大多数场景,可以避免大多数用户出现问题。静态扫描分为白盒扫描和AST扫描,AST可以从编译产物中发现隐藏的问题,避免诸如埋点事故等。

A10:

最小化暴露面:只公开必要的业务功能,不要在应用程序中包含未使用或不必要的功能。通过限制应用程序可以使用的API和权限,可以减少应用程序的攻击面。

加强身份验证:在应用程序中使用强密码、多因素身份验证和其他安全措施来确保只有授权用户才能访问敏感数据和功能。

安全存储数据:确保应用程序存储的数据被加密,包括用户个人信息、凭证和敏感数据等。

安全传输数据:使用安全传输协议,如HTTPS,确保应用程序和服务器之间的数据传输是加密的。

定期审查和更新:定期审查应用程序的代码和配置,以检测潜在的安全漏洞和缺陷。同时,更新应用程序和相关的库和框架,以获取最新的安全补丁和修复程序。

持续监控和响应:建立监控和警报机制,及时发现异常情况并采取必要的响应措施。

A11:

1、采用安全通信协议:在移动应用与后端服务器之间进行数据交互和通信时,应该采用安全通信协议,如HTTPS。HTTPS可以提供数据的加密、完整性保护和身份验证等功能,可以有效减少数据被拦截或篡改的风险。

2、使用安全的身份认证机制:在移动应用中,身份认证机制是非常重要的。应该采用安全的身份认证机制,如OAuth等。同时,在实现身份认证机制时,应该注意密码的安全性,如使用强密码和密码加密等措施,以避免密码被破解或泄露的风险。

3、限制数据访问权限:在移动应用中,应该根据用户角色和权限,限制数据的访问权限。对于一些敏感数据,应该只允许授权用户进行访问。同时,应该定期审查和更新权限配置,以确保权限控制的有效性。

4、使用安全的存储机制:在移动应用中,应该采用安全的存储机制,如加密存储等。对于一些敏感数据,应该采用更高级别的加密措施,以防止数据被窃取或泄露。

5、加强应用的安全测试:在开发移动应用时,应该加强应用的安全测试。可以采用黑盒测试、白盒测试等方式进行测试,以检测应用中的安全漏洞和风险,并及时进行修复。

Q:企业未来会像管理办公电脑一样管理移动设备吗?比如安装杀毒、安装数据防泄漏软件或者是限制安装未签名的移动软件?

A12

取决于移动端应用的使用程度,一般情况而言,都是不让敏感数据和重要数据转到移动端上更靠谱,移动端安全防护先天上来讲就不如终端电脑。

A13:

会有,不过都是公司发手机办公,在私人手机上装几乎不可能。

A14:

这个涉及边界问题,移动设备要如何界定工作终端和个人终端。

A15:

不用界定啊,只有公司的手机才能连啊。

A16:

移动端安全控制通过移动沙箱控制还是挺成熟的,数据不出空间,进出空间要经过认证。

A17:

移动肯定要管理起来,但是不一定是从终端上管理起来,可能是终端应用,移动门户。

A18:

业内有大规模使用手机沙箱吗?之前我下面兄弟调研过,说业内有用小规模的,但没有大规模使用。

A19:

有几个兄弟单位我们调研落地了,小范围,不如专用手机,卡顿,定制运营商保密线路,问题一大堆。

A20:

移动安全不晓得怎么做,业务安全我们还处于落后阶段,比市场上落后5年8年的,还是做运维好,我们的运维应该有市场平均水平,利润率也好。

A21:

现在就已经有移动终端管理了,只有体制内那些会对工作机进行移动终端管控,其他的企业一般都没有把工作手机和私人手机区分开,很难去推移动终端管理吧。

A22:

我记得现在有一些厂家提供一些远程接入都有提供虚拟系统进行操作远程,数据不落在本地的。

A23:

我有一个问题,现在不是有好多文件加密,然后移动端文件加密,拿出来也读不了,在APP内可以读,解密文件的KEY是在APP里,还是要读文件接口去调用解密,接口调用解密的KEY也存在KEY泄露吧?

A24:

那就是APK防破解的和源码审计的了。

A25:

手机是员工个人资产,除非涉密单位或特定单位,原则上不得强迫员工安装公司自己认定的软件。

 话题三 

单位的安全管理说说高位端口(大于1024以上的端口)不安全,对此表示不理解

A1:

默认端口才不安全吧。

A2:

是不是应该还有前置条件?比如说端口通常使用什么之类的?一般来说,管理要求是约定使用哪些端口,任意使用非管理要求的端口可能不受保护吧(因为不知道,基础架构又不能很好的匹配)。

A3:

1024为动态端口,无法确认使用应用,需要提交申请审批,留底。

A4:

1-1024端口基本上是对着服务的,你看端口基本知道是什么服务开启了。高位的端口,如果随便申请会导致后期信息资产采集无法确认承载的什么业务或者服务。如果按照他说的经过流程申请,那么资产信息就可以对得上。

从安全运营管理的角度上来说,资产管控不严带来的问题是很大的,可能会形成暗资产,或者脆弱点、暴露面。因此你们安全管理的需求,其实是合理的。

A5:

端口使用可以备案,审批啥的,但是高位端口不是不安全的端口。

A6:

也许也不太对,因为即使全部WEB都是80/443,也不一定知道这个80/443对应的资产或业务是啥。

A7:

80和443一般来说承载的是WEB应用,你不晓得具体是啥的WEB系统,但是你基本知道是WEB吗,当然没限制,胡乱使用80和443,当我没说,这种就属于极端情况了。

A8:

我认为还是要做好资产管理,单一从端口开放来管理服务还是有点不合理的,而且还指明高位端口不安全。

A9:

我觉得,任何端口的开放都应该需要走审批流程。

A10:

对的,都审批,并且对接CMDB、落库,这样是最好的。后续查资产申请人、使用目的、所属部门就都可以对上了。

A11:

这成本高了吧。

A12:

平台和流程搞起来,其实不高。你所谓的高,是指建设成本,还有定位责任。

A13:

安全运营用的资产、威胁、脆弱性,没有资产,后面两个无从谈起。

A14:

以前接收过最多的通报资产就是未知资产的漏洞,因为无法纳入管控,安全隐患极大。

A15:

安全管理总的来说做的是风险评估的事情,从风险评估的角度,只要是不在可控范围,就算安全风险和隐患。

A16:

如果安全不能管控网络出口或者在管控之前已经开放的在外部呢?

A17:

我们是审核流程加入了安全人员风险评估这一环节,已经开放在外部的,也定期风险评估,逐步收敛。

A18:

那是针对一些已经在管控,但是一些老早就开放的,没有经过评估的,就很难了,逐步但不是一步到位。而且有些单位资产确实太多了,下属公司、子公司、支撑单位这种大集团性质的,就很难搞。

A19:

是的,实际上一旦开出去,就很难关闭了,关闭端口也要领导审核,有时都找不到这个端口是为什么开的,但又不敢轻易关掉,一旦影响业务,就背锅了。

A20:

安全永远是为业务服务的,对于关不了的端口存在风险,可以写风险通知书,业务部门签字。对于风险 也是有接受这一条的。

A21:

所以,最好是能从源头,开端口环节,安全人员进行把控。

A22:

针对流程之后的可以有效管控,正常会有一个流转,业务提出需求-安全评估-业务不接受-风险责任书(除业务系统负责人,告知业务部门上级主管/负责人)-风险转移。当然具体看你们流程流转,但是肯定不是安全审批接受或者不接受风险的,安全负责告知风险。

FreeBuf 观点总结

随着ChatGPT的大火,我们也聊到了这类人工智能模型在网络安全中的运用,目前已有厂商开始试验一些实际场景,但伴随的数据泄露、泄密风险也让安全从业人员为之担忧,需要进一步细分各类应用场景,规范人工智能模型的运用。

近年来,移动化办公趋势越发明显,移动应用安全的重要性正日益凸显。在本期话题中,我们聊到了其中可能面临的安全问题,比如可能存在违规收集、使用、共享、转让或公开披露用户个人信息,以及因漏洞产生数据泄露、应用被逆向分析等。为了解决这些问题,可以归纳为应用层:对移动应用程序进行安全加固,进行安全测试和审计;制度层:建立并完善移动应用程序的个人信息保护制度和流程;培训层:对员工在移动应用办公过程中树立良好的网络安全意识。至于企业未来会像管理办公电脑一样管理移动设备,目前已有企业开始探索,但过程中仍涉及安全边界及资产归属等问题,需要进一步完善解决。

本期话题讨论到此结束啦~此外,FreeBuf甲方社群每周开展不同的话题讨论,快来扫码加入我们吧!

【申请流程:扫码申请-后台审核(2-5个工作日)-邮件通知-加入社群】

注:目前1群、2群已满,如有疑问,也可添加Kiki群助手微信:freebuf1024,

备注:甲方会员

“FreeBuf甲方群”帮会已建立,该帮会以三大甲方社群为基础,连接1100+甲方,持续不断输出、汇总各行业知识干货,打造网安行业甲方专属资料留存地。现“FreeBuf甲方群”帮会限时开放加入端口,让我们一同加入,共同建设帮会内容体系,丰富学习交流地。

FreeBuf甲方群成员(因篇幅限制仅展现部分行业成员):

金融行业:贝宝金融 安全负责人、成都农商银行 信息安全负责人、晋商银行 安全负责人、北京银行 安全负责人、君龙人寿 技术负责人、合合信息 合规负责人、合生 信息安全负责人、航天产业投资基金IT负责人、工银金融 信息安全负责人、前海联合基金 信息安全负责人、天弘基金 安全负责人、阳光保险 信息安全部负责人、南京证券 安全负责人、宝马金融 信息安全经理  

运营商中国联通 网络安全主管、中国电信 信息安全技术主管、上海电信 网络安全主管、天津电信SOC主管、太平洋电信 研发总监

互联网:云畅游戏 信息安全总监、飞点网络 技术总监、聚水潭科技 信息安全总监、诺亚控股 业务安全中心总监、哥伦比亚中国 信息安全总监非夕科技信息安全总监、赫基国际 信息安全部负责人、熵通科技 信息安全负责人、建发集团 信息安全经理 
其他:大学长教育 数据安全与合规总监、温州城市大学 信息技术服务中心科长、作业帮 安全负责人、同程艺龙 安全总监、新奥集团 安全总监、中译语通 安全总监、集贤科技 安全总监、德邦快递 安全总监、盒子科技 安全总监、猎豹移动 安全总监、蚂蚁集团 实验室负责人、结行科技 数据安全负责人、苏宁 网络安全经理、新浪 网络安全经理、吉利汽车 信息安全经理 
精彩推荐


文章来源: http://mp.weixin.qq.com/s?__biz=MjM5NjA0NjgyMA==&mid=2651222277&idx=1&sn=2019c1f1f695ae2714b178b29041a557&chksm=bd1de38e8a6a6a984b3d56c9fe480ab1ca0d43bbdff3a5fcaee944118dfbeb88355f5281c153#rd
如有侵权请联系:admin#unsafe.sh