2020年以来,金融服务企业面临着更多压力,比如供应链风险管理、预算和资源限制、以及缺乏安全培训等。
有一种说法,金融服务企业分两种类型:一种是曾经遭受过网络攻击;另一种是将会被攻击。这不是危言耸听,因为巨大的利润使得金融服务行业经常成为黑客首选的攻击目标。2019年,全球金融服务市场估值高达22万亿美元。疫情爆发的第一年,超过70%的金融服务企业都遭遇了网络攻击。
新思科技软件质量与安全部门亚太区客户服务总监Ian Hall指出:“这是金融服务企业面临的现实。为了转变AppSec实践并简化DevOps开发模型,企业一直在努力实施可扩展并能紧跟需求变化的工具和流程。管理和维护开源代码的复杂性、云原生架构和相关微服务的应用都给这项工作的开展增加了难度。此外,错综复杂的供应链使得企业很难全面了解其风险状况。”
尽管如此,因为金融服务行业的性质,许多人认为这个行业应该非常安全。以下是新思科技(Synopsys)使用2020年度“软件安全构建成熟度模型”(BSIMM)报告中的研究数据来揭示并解释金融服务行业安全的七大误区。
误区一:金融服务企业是安全的,因为他们必须安全
这种看法并不是基于证据或数据,而是基于这样一种信念:金融服务企业作为用户敏感数据的看门人,必须是安全的。
由于该行业受到严格监管,因此,金融服务企业往往非常善于保持合规性,从而导致安全主管和客户很容易产生错误的安全感。但如果他们不能仔细检查安全实践在合规范围外的表现,长期以往也会出现问题。
事实上,金融服务企业并没有那么安全。新思科技近期委托Ponemon Institute开展了一项名为《金融服务业的软件安全状况》的独立研究,凸显出人们对金融服务安全性的误解。报告发现,50%的金融服务企业由于不安全的软件而遭遇数据盗窃。
误区二:金融软件不同于其他软件(因此无法改变)
许多金融服务企业仍然认为他们的软件与其它类型的软件存在本质上的区别,因此无法做出改变。他们认为企业负担不起朝着DevOps做出重大转变的费用,也无法无条件地信任瀑布式方法等公认的最佳实践。他们的看法是,过去有效的方法未来将继续奏效。
其实金融软件的编写、管理和测试方式与其它软件大同小异。过时的开发模式会限制开发速度并阻碍上市速度。拒绝适应现代软件环境的企业迟早会落伍。
误区三:小型金融服务企业的AppSec需求有别于大型金融服务企业
有人误认为,小银行和大银行对AppSec和相对安全级别有着不同的需求。小银行通常是购买软件,而大银行则是自己开发软件。有人认为当购买软件时,确保安全性的责任便落在了供应商而不是购买者身上。此外,他们还认为小银行使用的软件不同于大银行,这种错误观点常常导致重要的安全实践活动被忽视。更令人不安的是,许多规模较小的银行认为自己的规模太小,不可能成为攻击目标。
所有的金融服务企业,无论规模大小,都依赖于开源软件和软件供应链——即使是那些自己开发软件的企业。客户对小银行和大银行的安全要求是一样的。因此,所有的银行都有责任实施可靠而全面的AppSec策略,并了解其安全风险状况。
误区四:企业可以控制所部署的软件中的所有内容
许多金融服务企业都认为,他们对其部署的软件中的所有组件和元素非常了解。但是,了解软件堆栈中的所有内容并不代表全面了解—— 甚至比较全面地了解 —— 它们在生产环境中的表现。即便是大型金融服务企业也陷入这个误区之中。
要知道,您所拥有的是不完整的视图。现在所有的金融服务企业都在使用各种形式的开源软件,覆盖广泛的AppSec活动和环境。从Docker和Kubernetes,到供应链、云部署和共担责任模式,您需要了解环境中的所有代码和每个组件。准确了解正在部署的内容及其安全状态是至关重要的。
误区五:确保云安全是云运营商和所有者的工作
就像对待第三方责任的态度一样,金融服务企业通常认为,在云安全问题上,有人可以“代劳”。金融服务企业以为云安全是云运营商和所有者的责任,通常基本或根本不会采取任何措施来保护其云部署。
实际上,确保云安全是企业本身的责任。GitHub、GitLab和其它各色云服务提供者都在努力保护用户的云部署。然而,能否确保部署安全仍然取决于贵企业的内部AppSec计划。为了运行安全的云部署,安全团队必须将安全的容器部署到云端。此外,金融服务企业还要负责整体的安全最佳实践、身份和访问管理以及加密安全。如果没有内部安全活动,云部署也许可以正常工作,但肯定不安全。
误区六:具备渗透测试、门禁测试和最后一步安全便足够
金融服务企业往往认为,开展渗透测试就足够了。这种测试的方法简易,再加上资源匮乏问题,很多企业误以为已经在现有条件下做到了最好。
需要强调的是,AppSec必须内置。虽然渗透测试确实能在应用安全方面起到关键作用,但仅开展渗透测试是不够的。新思科技的行业经验表明,在软件中发现的所有缺陷中有50%是架构缺陷,渗透测试无法检测到这些缺陷。金融服务企业需要采用深度架构风险分析(ARA)实践或威胁建模方法来识别这些重大风险。
误区七:开发人员可以根据经验自学AppSec技能
金融服务企业往往缺乏开展重要安全活动所需的资源。尽管如此,他们仍然相信只要有足够的时间和自学经验,开发人员便可以满足整个软件开发生命周期中的任何安全需求。
这种学习方式也许适用于少数开发人员,但在学习过程中产生的不良后果会给企业带来风险。开发人员需要多长时间才能成为安全专家的问题以及缺乏用技能评估架构和指标的问题,都构成了安全上的危险缺口。
然而,安全培训是必要的。Ponemon报告显示,只有38%的金融服务企业的员工具备保护软件所需的网络安全技能。25%的员工根本没有接受过安全培训,但仍然肩负着AppSec 的责任。
新思科技软件质量与安全部门高级安全架构师杨国梁总结道:“越来越多的金融服务机构都使用App来开展业务。但是便利性和安全隐患共生,软件安全问题不能小觑,比如高危漏洞、恶意程序或者使用第三方SDK时引入的安全风险等。金融服务企业无论是刚刚开始进行应用安全转型,还是正在逐步实现安全计划的更新与增强,都应该尽量安全‘左移’,用基于数据的策略来修正此类误区,以改进AppSec流程。”
好文章,需要你的鼓励
OpenAI CEO描绘了AI温和变革人类生活的愿景,但现实可能更复杂。AI发展将带来真正收益,但也会造成社会错位。随着AI系统日益影响知识获取和信念形成,共同认知基础面临分裂风险。个性化算法加剧信息茧房,民主对话变得困难。我们需要学会在认知群岛化的新地形中智慧生存,建立基于共同责任而非意识形态纯洁性的社区。
杜克大学等机构研究团队通过三种互补方法分析了大语言模型推理过程,发现存在"思维锚点"现象——某些关键句子对整个推理过程具有决定性影响。研究表明,计划生成和错误检查等高层次句子比具体计算步骤更重要,推理模型还进化出专门的注意力机制来跟踪这些关键节点。该发现为AI可解释性和安全性研究提供了新工具和视角。
传统数据中心基础设施虽然对企业至关重要,但也是预算和房地产的重大负担。模块化数据中心正成为强有力的替代方案,解决企业面临的运营、财务和环境复杂性问题。这种模块化方法在印度日益流行,有助于解决环境问题、满足人工智能的电力需求、降低成本并支持新一代分布式应用。相比传统建设需要数年时间,工厂预制的模块化数据中心基础设施可在数周内部署完成。
法国索邦大学团队开发出智能医学文献管理系统Biomed-Enriched,通过AI自动从PubMed数据库中识别和提取高质量临床案例及教育内容。该系统采用两步注释策略,先用大型AI模型评估40万段落质量,再训练小型模型处理全库1.33亿段落。实验显示该方法仅用三分之一训练数据即可达到传统方法效果,为医学AI发展提供了高效可持续的解决方案。