金融科技时代，无论是城商行、股份制银行，还是大型国有银行，都争相把IT能力快封转输出为科技能力甚至创办独立的科技公司，给金融单位服务以及给更多的同行业做输出，目的主要是让科技更快速的为金融业务服务，而最核心的是让资金流动性变得更好。
同时大家可能已经发现，商业银行安全部门的负责人们变得越来越忙，业务部门每上线一个新项目或重大更新迭代，都需要安全部门参与；因为没有安全介入，一些较大的变更和重要的业务已经推不动、走不通，说明安全已经伴随着IT成为一个非常重要的环节。
那么在科技引领的背景下，商业银行的安全体系怎样建设，安全能力怎样设计？又如何解决攻防不对称的问题呢？
近期，由默安科技主办、安全牛作为独家媒体支持的逐鹿安全沙龙——金融科技时代下的商业银行智能安全体系建设在杭州顺利举办。来自江苏银行、宁波银行、泰隆银行、杭州银行、浙商银行、中国银行、浙江省农信等多家商业银行界的安全专家参会并就自身实践进行了探讨。
攻防不对称的“解药”——欺骗防御
江苏银行的安全经理王心玉根据自己在银行互联网安全领域的实践提出三种更容易理解的安全论点：看不见的安全、看得见的安全，以及看不懂的安全。
看不见的安全
把安全变成提供一种透明的服务，应对快速业务发展，为应用提供支撑各种信任关系的服务集合，包括手机认证、app安全加固、设备指纹、生物识别等。
看得见的安全
在这一块需要清楚地掌握资产的脆弱性，以及面临的威胁；做好边界和资产，比如公网IP地址、域名、开放端口及应用服务的安全管理；结合场景和日志分析平台做好风险关联分析和展现。
看不懂的安全
提出这一点，是考虑怎样做一些更加精准的判断，试图解决攻防不对称问题，江苏银行使用了业务伪装代理与追踪溯源类的产品，来解决“看不懂的安全”这一块的难题。
关于攻击欺骗与诱捕防御中经常会遇到的问题，王心玉给出了他的答案。
会不会导致网页篡改，从而引发本机构声誉风险？
不会。
伪装代理并不模拟真实网站，一般会伪装成数据库端口、远程管理端口或后台管理控制台。
伪装代理由于是与本机构业务系统绑定，会不会被攻破从而被攻击者大肆宣扬？
不会。
互联网上配置的伪装代理与传统故意放置漏洞的蜜罐系统不同之处在于：
1）伪装代理更像是灵敏度极高的探针，允许对方多种攻击试探，记录行为的同时控制不被攻破；
2）伪装代理采用动态沙箱机制，交互设计会给攻击者一种错觉，以为攻击成功，但实际执行不了任何命令，做不了任何操作。
外部检查会不会认为是漏洞或不必要的服务，要求整改？
1）做好向监管部门的报备工作；
2）记录并提供后台详细攻击或探测日志以澄清。
王心玉认为，攻击欺骗与诱捕防御对银行、监管部门、公安机关和社会公众都具有价值与意义。
SDL怎么落地？平台赋能沟通一个也不能少
宁波银行安全专家周聪介绍了宁波银行目前物理安全、网络安全、主机安全，以及终端安全等的基本情况，以及SDL应用安全体系的实践。
SDL应用安全体系中存在的问题：
· 安全测试门槛高，安全测试专业人员少
· 互联网系统较多，部分系统功能模块较复杂
· 扫描辅助工具作用甚微，且误报率高
根据SDL实践方法，宁波银行建立了应用开发安全生命周期管理流程，强化对信息系统需求、设计、开发、测试等环节安全控制节点管控，从源头上降低信息系统安全风险。具体的实施包括应用开发安全规范，到过程控制中的需求分析、设计、开发、准出把关等环节。
宁波银行在年初上线了默安科技的雳鉴产品的黑盒部分，周聪从自动化和可视化等两个方面描述了该产品为整个体系建设带来的好处。
基于宁波银行在应用安全体系的实践，周聪提出自己对于自动化安全测试平台的思考。
根据“木桶原理”，一家银行的安全性如何，取决于最短的那块木板
鉴于越来越多系统移动化，应该将涉及重要敏感信息和资金的系统接入平台，提升整体安全防控水平；
平台赋能专家
一个平台能达到多少功效，与自身能力水平挂钩，业务逻辑漏洞需要更专业的安全人员将产品价值最大化。明年将探索通过平台实现业务逻辑漏洞自动化测试及自定义漏洞规则；
更小成本换来最大收益
多与研发测试人员沟通，听其诉求，尽可能降低安全管理对其工作的影响，能够得到认同但同时不影响效果；多与厂商沟通，探索平台更智能，更人性化，用更简单方式、更小成本换来同样的安全收益。
让开发安全机械化、自动化
基于金融科技时代下的业务视角，默安科技华北运营中心技术副总裁贾大伟分享了他在安全开发领域的实践与思考。
现在金融监管部门对金融客户不仅仅验证响应能力，同时还验证效能能力，也就是在考验在最短时间内完成处置的能力。
传统的做法是基于具体问题成立项目组开会讨论解决办法，需要经过代码修复、安全复测、业务测试、上报整改方案等一系列过程，这个过程中体现了跨部门协作的问题以及对于特定漏洞需要专业人员去服务的问题，耗费时间较长。
目前从全行业来看，金融机构普遍存在的问题有以下几点：
· 安全开发的水平由于受到开发人员的影响参差不齐、人力不够；
· 没有完整或者适用性比较强的开发安全管理体系；
· 开发安全工具效果不理想，检测结果无法给研发；
· 未实现全面系统的源代码检测。
默安的开发安全方案打造了一个机械化的1.0阶段的引擎，帮助安全部门和测试部门建立桥梁，试图让测试部门更早的将安全问题解决，将漏洞检测平台化、工具实现自动化，目前产品已经到了测试用例定制化的过程，能够为更多客户实现自定义业务场景的自动化落地测试。
在开发安全方面，未来产品线的业务定位不仅仅要测试出更多漏洞，更应该知道业务是怎么流转的。不能仅仅只测试表面的交易请求，还需要测试背后的接口，包括监管单位的接口和供应商的接口。作为安全开发能力的提供方，默安未来将给金融机构提供开放平台，面向复杂业务场景，默安将向下提供核心接口和落地测试用例服务，向上提供管理API，与内部管理平台打通，横向提供与威胁建模的映射管理，从而让安全专家可以专心研究风险，并对已知风险进行自动化测试。
小组讨论问题集锦
小组讨论环节，与会嘉宾就蜜罐产品的监管、诱捕防御与现有安全防护体系、威胁建模、安全和研发测试跨部门协作等问题进行了热烈的探讨。
全新业务或者创新功能的威胁建模如何进行？
微软最开始的威胁建模，解决方法一般是数据流程图，国内目前比较先进的是知识库的形式，但问题是出来的威胁模型比较粗糙，不可能十几个问题就把所有的威胁都描述清楚，需要后面再进行一次细致的评估。
目前比较有效的办法是先把项目数据结构的流程图画出来，然后用checklist的分析方法，对应到数据流程图里，分析可能会出现什么样的威胁。
基于溯源出来的网络身份，各银行是否愿意提交网络身份给第三方协调实验室，来进一步确认身份？
关于溯源出来的网络身份，银行嘉宾表示，对于那些公开的网络身份如网络ID，可以分享，但一些非公开的身份，需要司法机构通过合法流程才能拿得到。
安全开发流程如何与现有的开发流程有效融合？
开发在引入之前，先开展技术评审会，产品能否引入，是否符合银行架构方面、系统方面、网络方面、安全方面的要求，通过之后召开项目启动会。
目前，安全直接介入的包括项目启动、需求和设计评审，以及上线前这三个环节。额外的安全工作，则是赋能给研发管理部的QA，由他们检查是否合规，然后由安全团队进行抽查，QA是否在按照设定的计划在履行，研发是否按照需求checklist去建设，通过这样实现一个安全管理的闭环。
也有嘉宾表示，在安全介入时，研发和测试人员不太配合的问题，导致SDL难以推动，很大一部分原因是大家对安全的理解不在一个层面上，需要有个协作的平台，然后配合上安全培训的宣贯来解决这个问题。
来源：freebuf.com 2018-12-20 11:01:53 by: 默安科技
请登录后发表评论
注册