精华内容
下载资源
问答
  • 2017-10-12 19:46:34


    什么是 SDL

    Simple DirectMedia Layer(SDL)是一个跨平台开发库,主要提供对音频,键盘,鼠标,操纵杆的操作,通过OpenGL和Direct3D来实现直接访问图像硬件。 主要应用在视频播放软件,模拟器和游戏开发。SDL官方支持Windows,Mac OS X,Linux,iOS和Android。在源代码中可以找到对其他平台的支持。
    SDL是用C编写的,我们可以使用C ++开发,同时SDL也绑了一些其他几种语言,包括C#和Python。
    这个库是分布在zlib许可证下,可以找到在文件“COPYING.txt”。如果想要快速的掌握SDL,去阅读下头文件以及test下的测试代码,那里面有更多示例教程,以及很好的注释,帮助你去学习,理解,掌握.
    

    SDL库分为 Video、Audio、CD-ROM、Game、Joystick 和 Timer 等若干子系统,除此之外,还有一些单独的官方扩充函数库。这些库由官方网站提供,并包含在官方文档中,共同组成了SDL的“标准库”,具体如下:
    SDL_image—支持时下流行的图像格式:BMP、PPM、XPM、 PCX、GIF、JPEG、PNG、TGA。
    SDL_mixer—更多的声音输出函数以及更多的声音格式支持。支持常见的WAV,MP3,OGG等基础格式。
    SDL_net—网络支持。
    SDL_ttf—TrueType字体渲染支持。
    SDL_rtf—简单的RTF渲染支持

    SDL 子系统

    SDL将功能分成下列数个子系统(subsystem):
    Video(图像)—图像控制以及线程(thread)和事件管理(event)。
    Audio(声音)—声音控制
    Joystick(摇杆)—游戏摇杆控制
    CD-ROM(光盘驱动器)—光盘媒体控制
    Window Management(视窗管理)-与视窗程序设计集成,不过android默认就是对应的surfaceView的窗口,只允许存在一个。
    Event(事件驱动)-处理事件驱动
    haptic 触摸事件响应
    Time 时间管理

    SDL 整体框架

    SDL的整个框架结构:这里我们可以看到,SDL是个跨平台多支持的渲染框架,完成在硬件驱动层之上的抽离,实现Window linux Android等一系列平台的适配。如此,我们可以使用SDL完成我们的逻辑开发,便可以快速编译到各个平台,实现跨平台。


    SDL 可以干什么

    视频
    3D图形:
    SDL可以与OpenGL API或Direct3D API结合使用,用于3D图形
    加速2D渲染API:
    支持简单旋转,缩放和Alpha混合,所有这些都使用最新的3D API加速
    使用OpenGL和Direct3D支持加速
    创建和管理多个窗口
    输入事件
    提供的事件和API方法如下:
    应用程序和窗口状态更改
    鼠标输入
    键盘输入
    操纵杆和游戏控制器输入
    多点触控手势
    可以使用SDL_EventState()启用或禁用每个事件
    在发布到内部事件队列之前,事件将通过用户指定的过滤器函数传递
    线程安全事件队列
    音频
    设置8位和16位音频,单声道立体声或5.1环绕声的音频播放,如果硬件不支持格式,可选择转换
    音频在单独的线程中独立运行,通过用户回调机制处理
    专为自定义软件音频混音器而设计,其中SDL_mixer提供完整的音频/音乐输出库
    文件I / O抽象
    通用抽象开放,读写数据
    内置支持文件和内存支持
    共享对象支持
    加载共享对象(Windows上的DLL,Mac OS X上的.dylib,Linux上的.so)
    共享对象中的查找方法,调用
    线程
    简单线程创建API
    简单线程本地存储API
    互斥量,信号量和条件变量
    用于无锁编程的原子操作
    计时器
    获取流逝的毫秒数
    等待指定的毫秒数
    在单独的线程中创建与代码并行运行的计时器
    使用高分辨率计数器进行分析
    CPU特征检测
    查询CPU数量
    检测CPU功能和支持的指令集
    支持大小端检测
    检测当前系统的字节顺序
    用于快速交换数据值的例程
    读取和写入指定字节数据的数据
    电源管理
    查询电源管理状态

    SDL的总体概况

    SDL主要围绕着实现一套快速渲染的框架,同时能够兼容更多平台。除了渲染之外,做了一些外围扩展,比如播放更多音频格式,支持渲染TTF字体,支持加载更多图片格式,同时实现了网络请求。除此之外,SDL直接能做的事情确实比较少,需要我们自己去扩展,去将三方的其他库封装过来,以便提供更强大的开发支撑。
        从现在开始,我会带领大家,一起领略SDL的风采,在快速学习掌握使用的基础上,进行原理学习,技能扩展,提升。本书会从Android平台进行切入,讲解。
    在完成原理,使用讲解之后,我会移植一些开源库,来支援SDL框架,使得SDL可以开发简单,轻量级别的游戏。
        那么你准备好了吗?

    更多相关内容
  • 个人介绍 滴滴SDL建设历程概览 滴滴SDL建设历程详解 滴滴SDL现在与未来
  • SDL体系落地实践与系统实现: 什么是SDL? SDL困难三重奏! 猪八戒网SDL流程实践。 未来SDL规划~
  • 「web安全」滴滴SDL体系建设 - 安全建设 DDoS 安全开发 数据治理 系统安全 安全意识
  • 「自动化」滴滴SDL体系建设--滴滴SDL从0-1建设历程 - 攻防实训 安全认证 系统安全 应用安全 信息安全 安全知识
  • 去哪儿网 去哪儿是全球最大的中文在线旅行网站,创立于2005年。去哪儿网为消费者提供国内外特价机票、...作为洞态 IAST 最早期版本的用户,去哪儿在 IAST 与其 Q-SDL 安全体系的融合适配上有着独到的见解,十分感谢去

    去哪儿网
    去哪儿是全球最大的中文在线旅行网站,创立于2005年。去哪儿网为消费者提供国内外特价机票、酒店、旅游度假、景点门票产品一站式预订服务,为旅游行业合作伙伴提供在线技术、移动技术解决方案。去哪儿近年来,接连发力大数据与人工智能,利用出游、住宿等领域的全量数据和人工智能,为用户打造智能化搜索、排序、推荐等服务。目前,去哪儿用户累计超6亿,平台年交易额超1600亿,且仍在快速发展中。

    作为洞态 IAST 最早期版本的用户,去哪儿在 IAST 与其 Q-SDL 安全体系的融合适配上有着独到的见解,十分感谢去哪儿 Q-SDL 负责人耿师傅对本次 IAST 实践的分享。

    01 安全背景

    新政策、新业务、新威胁
    近年来,国家愈发重视信息安全,《网络安全法》、《数据安全法》、《个人信息保护法》相继出台并施行,对互联网企业提出了更严格的安全要求。在业务上,互联网企业的业务边界不断拓宽,用户和年交易额等均实现持续发展,业务保障需求更强。但技术研发成本不断攀升、盈利增速下降都促使着以业务为主的企业,更加注重在安全上的“高产出”。据可查数据,自疫情爆发以来,黑客针对国内互联网企业的攻击几乎呈现指数级增长,企业面临的安全威胁极大。

    在这样的背景下,互联网企业的网络安全能力建设,尤其是应用开发期的安全能力建设显得格外重要。阿里、腾讯、字节、去哪儿、轻松筹等企业均在着力强化应用安全开发,试图在应用开发期便大幅降低安全风险。DevSecOps 流程、SDL 流程在各企业都已早早落地实践运行,并打造适配其业务场景的安全体系。

    安全需求
    去哪儿结合自身实际,打造了 Q-SDL 体系。Q-SDL 体系通过预防、检测和监控措施相结合的方式,减少设计、开发中的软件的漏洞数量和严重性问题,降低应用安全开发和维护的总成本,保证系统的安全性。
    在这里插入图片描述

    从上图可知,用于安全漏洞检测的自动化工具仅包括 SAST 和 DAST,但 SAST 和 DAST 均具有不可避免的严重缺陷。

    我们在实际运行中发现,白盒测试存在误报率高、审计时策略规则失效明显、扫描效率低下严重阻碍开发节奏等问题,尤其是无法获取漏洞数据对安全部门造成了很大困扰。而黑盒覆盖范围有限,覆盖率依赖于 Explore 的结果,无法扫描 AJAX、CSRF Token、验证码等页面,无法测试 APP,无法定位漏洞的具体代码,需要花费较长时间与人力来进行漏洞定位与原因分析。

    去哪儿急需一款能够弥补黑盒和白盒不足的产品来完善 Q-SDL 体系。

    02 调研之路

    考虑到开源产品具备高扩展性、低使用成本的特性,我们首先将选择定位在开源产品上。由于当时市面上只有开源的 RASP,而没有开源的 IAST,因此首先调研的是 RASP。但调研后发现 RASP 存在严重影响服务器性能的问题,恰巧在了解 RASP 的过程中,发现火线安全正在研发 IAST,并打算开源发布,于是便进行了接触。以下为洞态 IAST 调研结果:

    IAST 全称交互式应用程序安全测试,主要通过 Agent 来收集和监控应用程序运行时的函数执行及数据传输,并与服务端进行实时交互,进而更高效、更准确的识别应用软件的安全缺陷及漏洞。同时可准确定位漏洞所在的代码文件、行数、函数及参数,方便开发团队修复问题,还具备高低误报率、0脏数据的优势。但 IAST 在不同语言开发的 WEB 应用中需要有不同类型的 Agent、研发的技术难度和投入都非常巨大。

    洞态 IAST 产品架构
    在调研中我们发现洞态 IAST 在架构上完全不同于其他 IAST,其他 IAST 往往 “重 Agent 端、轻服务端”,而洞态的 Agent 端仅用于实现数据监听,漏洞检测全部在服务端完成。这种方法的好处是 Agent 端代码和逻辑简单,单点故障率更低也极少需要升级,降低了维护成本;另外,传统 IAST 产品对于当时未检测的漏洞都在 Agent 端直接丢弃,产品出现新的检测策略后,需要重新发起应用的测试,而洞态 IAST 将检测数据保存在服务端,可轻松地在服务端进行回归测试。
    在这里插入图片描述

    产品架构说明:首先,在服务器上安装 IAST Agent。当 IAST 启动,用户访问 Agent 服务后,Agent 便开始采集数据,并与 OpenAPI 服务通信,进行上报数据和Hook规则的拉取。OpenAPI 将数据存储到数据库中,包括 MySQL 和 Redis。然后,Agent 对 Engine 发送通知,Engine 便会来消费数据库中的数据,并在分析完毕后将漏洞信息回写到数据库中。最后,用户通过 WebAPI 查看数据库中漏洞的数据信息。

    洞态 IAST 检测原理
    洞态基于“值匹配算法“和”污点跟踪算法”对漏洞进行检测。这种算法检测准确率高,还无需采集和重放流量,可以适配如今各种场景下的漏洞检测(如 API 网关、分布式、微服务等架构下的后端服务漏洞检测),还不会产生脏数据,干扰正常的开发测试流程。
    在这里插入图片描述对于检测发现的漏洞,洞态根据外部可控数据的传播过程,完整的还原漏洞触发流程,帮助 DevOps 团队快速理解漏洞、定位漏洞,更好的解决漏洞。通过赋能研发人员,提高漏洞修复的效率。

    洞态 IAST 产品优势

    • 第三方开源组件漏洞分析
    • 应用漏洞溯源、定位与分析
    • 应用漏洞自动验证
    • 全面的风险监测
    • 开源带来低成本、高扩展、多策略和多场景

    促使我们选择洞态 IAST 的原因,除以上产品优点外,还有洞态团队对 IAST 部署升级的全力支持。如果我们选择其他厂商的 RASP/IAST,不一定能得到全力支持。

    03 IAST 实践

    去哪儿部署洞态 IAST 已经有半年多的时间,特分享一下 IAST 实践经验。

    IAST 应用于Q-SDL体系
    在 Q-SDL 体系中,IAST 承担测试的角色,并且打造了 IAST 平台收集漏洞信息数据。
    在这里插入图片描述
    部署适配
    在 Q-SDL 体系中部署 IAST,主要是从基础环境、应用环境、生命节点上进行适配,并在具体的点上进一步优化。

    在去哪儿,IAST Agent 的部署环境包括容器与虚拟机二种。采用分布式部署的方式,提高系统的可靠性与可用性,并对二种不同环境开发一套标准流程,保证 Agent 在不同环境的标准化部署。部署完毕后,需要将安装 Agent 的机器所在的网络和 Agent 接收数据的 OpenAPI 之间的网络打通,使 OpenAPI 能接收数据。

    在实际应用上,通过二次开发,扩展 IAST 的功能,并推动和去哪儿其他安全工具的融合。通过洞态 IAST Agent 收集识别企业资产,从而对整个资产进行漏洞检测。为应对 IAST 运行过程中可能出现影响业务等问题,我们提出了二套解决方案。一是“软着陆”,即通过洞态 IAST 自带的解决方案,直接删除核心模块;二是“硬着陆”,基于去哪儿强大的 API 直接将 IAST Agent 端去除。但我们使用这么长时间,还没出现过严重的问题。

    在使用中,我们并不是将 IAST 孤立地用来检测。而是把威胁信息和项目信息,上传至去哪儿的威胁建模平台,然后将 IAST、DAST 和 SAST 做相应的配合,有针对性地检测某些漏洞,提高检测率。

    私有云部署场景及方案
    在这里插入图片描述

    对于私有云部署场景,我们主要做了二点变动:第一点是在 IAST Agent 部署时,把 Agent 包直接放入镜像指定目录,以应对庞大的测试流量。另一点是对 Agent 端启动命令进行植入,以适配标准化环境,从而有序地执行,不去抢占其他环境变量的资源,发生冲突。

    整体的部署方案是遵循洞态 IAST 的基础部署方案,我们只做了微调。业务端 Agent 没有做太大的改变,仅对 Java 包进行了二次开发。为防止应用高流量高并发导致 IAST 超载,针对性地开发了负载均衡功能。而在 IAST 分析模块上,我们将 Redis 独立出来,并做得更强大些以应对高流量高并发。

    以下为我们去哪儿网络进出口的真实情况:
    在这里插入图片描述

    为控制突发性的高流量,我们采用了 “自适应流量采集+分布式架构” 的方案。自适应流量采集将无效的流量过滤,分布式架构则可灵活支撑高并发,减轻流量压力。

    运行流程
    在这里插入图片描述

    实际使用感受
    1.值得称赞的点

    • 应用威胁识别广泛

    我们在上线前利用靶场做过了大量测试,才放心将洞态IAST上线。IAST检测到的漏洞类型几乎覆盖所有的通用漏洞,包括(持续增加中):

    • 组件威胁识别率高

    IAST上线后发现了大量的组件威胁,具体数量等信息就不方便透露咯。

    • 技术真材实料,服务尽心尽力

    2.吐槽

    • 高危漏洞检出率较低

    洞态说明:因为去哪儿部署的是最早一版的洞态,出于稳定性考虑,还未进行版本更新,因此在检测能力上相对新版本会差许多。但洞态会加强研发力度,持续扩大可检测漏洞类型以及高危漏洞的检出率。

    洞态:去哪儿的 IAST 实践亮点在于擅长将 IAST 与自身 Q-SDL 体系的适配,也善于从自身所处互联网行业高流量高并发的特点出发,通过开发负载均衡功能、对 IAST 模块进行调整、扩展开发等手段,将 IAST 的作用发挥到极致,也希望大家都能从去哪儿的安全智慧中找到灵感。

    关于洞态 IAST

    洞态 IAST 是全球首个开源 IAST 产品,于2021年9月1日正式开源发布。洞态 IAST 专注于 DevSecOps,具备高检出率、低误报率、无脏数据的特点,帮助企业在应用上线前发现并解决安全风险。自开源发布以来,洞态 IAST 备受开源社区人员和企业的关注,包括工商银行、去哪儿、知乎、同程旅行、轻松筹等在内的上百家企业都已成为洞态用户。

    官网地址:http://dongtai.io

    展开全文
  • IAST 应用于Q-SDL体系 在 Q-SDL 体系中,IAST 承担测试的角色,并且打造了 IAST 平台收集漏洞信息数据。 上线 IAST 后的 Q-SDL 体系架构 部署适配 在 Q-SDL 体系中部署 IAST,主要是从基础环境、应用环境、生命节点...

    去哪儿网

    去哪儿是全球最大的中文在线旅行网站,创立于2005年。去哪儿网为消费者提供国内外特价机票、酒店、旅游度假、景点门票产品一站式预订服务,为旅游行业合作伙伴提供在线技术、移动技术解决方案。去哪儿近年来,接连发力大数据与人工智能,利用出游、住宿等领域的全量数据和人工智能,为用户打造智能化搜索、排序、推荐等服务。目前,去哪儿用户累计超6亿,平台年交易额超1600亿,且仍在快速发展中。

    作为洞态 IAST 最早期版本的用户,去哪儿在 IAST 与其 Q-SDL 安全体系的融合适配上有着独到的见解,十分感谢去哪儿 Q-SDL 负责人耿朋敲对本次 IAST 实践的分享。

    01 安全背景

    去哪儿是典型的互联网公司,其安全建设路线适用于绝大多数从业者参考。

    从基础安全细分到SDL领域,作为⼤多数安全⼯程师⽇常⼯作之⼀,⾃动化、平台化、有效运营也⼀直是安全体系建设中很重要的⼀环。

    DAST最早发展,SAST紧跟其后,IAST后起 之秀,应求同存异互为补充,并不能割裂的看待⿊⽩灰三款产品。

    --安全乐观主义点评

    新政策、新业务、新威胁

    近年来,国家愈发重视信息安全,《网络安全法》、《数据安全法》、《个人信息保护法》相继出台并施行,对互联网企业提出了更严格的安全要求。在业务上,互联网企业的业务边界不断拓宽,用户和年交易额等均实现持续发展,业务保障需求更强。但技术研发成本不断攀升、盈利增速下降都促使着以业务为主的企业,更加注重在安全上的“高产出”。据可查数据,自疫情爆发以来,黑客针对国内互联网企业的攻击几乎呈现指数级增长,企业面临的安全威胁极大。

    在这样的背景下,互联网企业的网络安全能力建设,尤其是应用开发期的安全能力建设显得格外重要。阿里、腾讯、字节、去哪儿、轻松筹等企业均在着力强化应用安全开发,试图在应用开发期便大幅降低安全风险。DevSecOps 流程、SDL 流程在各企业都已早早落地实践运行,并打造适配其业务场景的安全体系。

    安全需求

    安全建设的需求来源于法律政策、用户信任、金融合规等。

    研发安全说白了就是各种“扫”,引入新的IAST技术降本增效提高生产力是SDL运营的必经之路。

    还有两个隐含的需求:一、公司里没有那么多专业的安全开发去做新产品;二、存量漏洞不断被发现,增量如何管控,我们真的安全左移了吗?

    --安全乐观主义点评

    去哪儿结合自身实际,打造了 Q-SDL 体系。Q-SDL 体系通过预防、检测和监控措施相结合的方式,减少设计、开发中的软件的漏洞数量和严重性问题,降低应用安全开发和维护的总成本,保证系统的安全性。

    02ef1f73df65932d8522e4b46d5e74f1.png

    未上线 IAST 前的 Q-SDL 体系架构

    从上图可知,用于安全漏洞检测的自动化工具仅包括 SAST 和 DAST,但 SAST 和 DAST 均具有不可避免的严重缺陷。

    我们在实际运行中发现,白盒测试存在误报率高、审计时策略规则失效明显、扫描效率低下严重阻碍开发节奏等问题,尤其是无法获取漏洞数据对安全部门造成了很大困扰。而黑盒覆盖范围有限,覆盖率依赖于 Explore 的结果,无法扫描 AJAX、CSRF Token、验证码等页面,无法测试 APP,无法定位漏洞的具体代码,需要花费较长时间与人力来进行漏洞定位与原因分析。

    去哪儿急需一款能够弥补黑盒和白盒不足的产品来完善 Q-SDL 体系。

    02 调研之路 

    千⾥之堤毁于蚁穴,与外挂式安全产品不同,对业务⽽⾔IAST的性能/稳定性/可⽤性保障是优先于其安全增益属性的,需要先考虑可实施性,在其之上再考虑安全能⼒。

    Agent端作为sensor轻量化的设计解耦安全逻辑,其性能及维护成本优势显⽽易⻅。污点跟踪与传播,被动式的基于堆栈数据流维度漏洞检测分析与SAST殊途同归。

    在最近Log4j2推修中,各家苦于收集受影响资产时,拓展性的SCA将成为有效助⼒的解决⽅案。

    --安全乐观主义点评

    考虑到开源产品具备高扩展性、低使用成本的特性,我们首先将选择定位在开源产品上。由于当时市面上只有开源的 RASP,而没有开源的 IAST,因此首先调研的是 RASP。但调研后发现 RASP 存在严重影响服务器性能的问题,恰巧在了解 RASP 的过程中,发现火线安全正在研发 IAST,并打算开源发布,于是便进行了接触。以下为洞态 IAST 调研结果:

    IAST 全称交互式应用程序安全测试,主要通过 Agent 来收集和监控应用程序运行时的函数执行及数据传输,并与服务端进行实时交互,进而更高效、更准确的识别应用软件的安全缺陷及漏洞。同时可准确定位漏洞所在的代码文件、行数、函数及参数,方便开发团队修复问题,还具备高低误报率、0脏数据的优势。但 IAST 在不同语言开发的 WEB 应用中需要有不同类型的 Agent、研发的技术难度和投入都非常巨大。

    洞态 IAST 产品架构

    在调研中我们发现洞态 IAST 在架构上完全不同于其他 IAST,其他 IAST 往往 “重 Agent 端、轻服务端”,而洞态的 Agent 端仅用于实现数据监听,漏洞检测全部在服务端完成。这种方法的好处是 Agent 端代码和逻辑简单,单点故障率更低也极少需要升级,降低了维护成本;另外,传统 IAST 产品对于当时未检测的漏洞都在 Agent 端直接丢弃,产品出现新的检测策略后,需要重新发起应用的测试,而洞态 IAST 将检测数据保存在服务端,可轻松地在服务端进行回归测试。 

    c58fbb6c690271e8940e6a175af43b23.png

    产品架构说明:首先,在服务器上安装 IAST Agent。当 IAST 启动,用户访问 Agent 服务后,Agent 便开始采集数据,并与 OpenAPI 服务通信,进行上报数据和Hook规则的拉取。OpenAPI 将数据存储到数据库中,包括 MySQL 和 Redis。然后,Agent 对 Engine 发送通知,Engine 便会来消费数据库中的数据,并在分析完毕后将漏洞信息回写到数据库中。最后,用户通过 WebAPI 查看数据库中漏洞的数据信息。

    洞态 IAST 检测原理

    洞态基于“值匹配算法“和”污点跟踪算法”对漏洞进行检测。这种算法检测准确率高,还无需采集和重放流量,可以适配如今各种场景下的漏洞检测(如 API 网关、分布式、微服务等架构下的后端服务漏洞检测),还不会产生脏数据,干扰正常的开发测试流程。

    b1fa0232bd660ab1a3abac49277de001.png

    对于检测发现的漏洞,洞态根据外部可控数据的传播过程,完整的还原漏洞触发流程,帮助 DevOps 团队快速理解漏洞、定位漏洞,更好的解决漏洞。通过赋能研发人员,提高漏洞修复的效率。 

    洞态 IAST 产品优势

    • 第三方开源组件漏洞分析

    • 应用漏洞溯源、定位与分析

    • 应用漏洞自动验证

    • 全面的风险监测

    • 开源带来低成本、高扩展、多策略和多场景

    促使我们选择洞态 IAST 的原因,除以上产品优点外,还有洞态团队对 IAST 部署升级的全力支持。如果我们选择其他厂商的 RASP/IAST,不一定能得到全力支持。

    03 IAST 实践 

    分布式部署、所有接⼝API化,可根据企业实际场景⼆次开发融入⾃⾝DecSecOps体系。

    实践中建议先增加产品覆盖率,别的评价指标体系以后再说,安全也要相信大力出奇迹。

    --安全乐观主义点评

    去哪儿部署洞态 IAST 已经有半年多的时间,特分享一下 IAST 实践经验。

    IAST 应用于Q-SDL体系

    在 Q-SDL 体系中,IAST 承担测试的角色,并且打造了 IAST 平台收集漏洞信息数据。

    eaeb55a109b4aaae1285b7fec281c49b.png

    上线 IAST 后的 Q-SDL 体系架构

    部署适配

    在 Q-SDL 体系中部署 IAST,主要是从基础环境、应用环境、生命节点上进行适配,并在具体的点上进一步优化。

    fa660a900f221e94abec788a067b41ad.png

    在去哪儿,IAST Agent 的部署环境包括容器与虚拟机二种。采用分布式部署的方式,提高系统的可靠性与可用性,并对二种不同环境开发一套标准流程,保证 Agent 在不同环境的标准化部署。部署完毕后,需要将安装 Agent 的机器所在的网络和 Agent 接收数据的 OpenAPI 之间的网络打通,使 OpenAPI 能接收数据。

    在实际应用上,通过二次开发,扩展 IAST 的功能,并推动和去哪儿其他安全工具的融合。通过洞态 IAST Agent 收集识别企业资产,从而对整个资产进行漏洞检测。为应对 IAST 运行过程中可能出现影响业务等问题,我们提出了二套解决方案。一是“软着陆”,即通过洞态 IAST 自带的解决方案,直接删除核心模块;二是“硬着陆”,基于去哪儿强大的 API 直接将 IAST Agent 端去除。但我们使用这么长时间,还没出现过严重的问题。

    在使用中,我们并不是将 IAST 孤立地用来检测。而是把威胁信息和项目信息,上传至去哪儿的威胁建模平台,然后将 IAST、DAST 和 SAST 做相应的配合,有针对性地检测某些漏洞,提高检测率

    私有云部署场景及方案

    f8cd86bd590213130acacfcc0e4eed5e.png

    对于私有云部署场景,我们主要做了二点变动:第一点是在 IAST Agent 部署时,把 Agent 包直接放入镜像指定目录,以应对庞大的测试流量。另一点是对 Agent 端启动命令进行植入,以适配标准化环境,从而有序地执行,不去抢占其他环境变量的资源,发生冲突。

    194f4e51ee634e7a38deb345d5a2b174.png

    整体的部署方案是遵循洞态 IAST 的基础部署方案,我们只做了微调。业务端 Agent 没有做太大的改变,仅对 Java 包进行了二次开发。为防止应用高流量高并发导致 IAST 超载,针对性地开发了负载均衡功能。而在 IAST 分析模块上,我们将 Redis 独立出来,并做得更强大些以应对高流量高并发。

    以下为我们去哪儿网络进出口的真实情况:

    8c5389e31585a27840452ba0131c7002.png

    为控制突发性的高流量,我们采用了 “自适应流量采集+分布式架构” 的方案。自适应流量采集将无效的流量过滤,分布式架构则可灵活支撑高并发,减轻流量压力。

    运行流程

    0a354d6152d57ae86bdd245ad45709bc.png

    实际使用感受:

    1. 值得称赞的点

    • 应用威胁识别广泛

    我们在上线前利用靶场做过了大量测试,才放心将洞态IAST上线。IAST检测到的漏洞类型几乎覆盖所有的通用漏洞,包括(持续增加中):

    7e3020cb5cd3725da1b3906b2773d657.png

    • 组件威胁识别率高

    IAST上线后发现了大量的组件威胁,具体数量等信息就不方便透露咯99f80db53ec806361900393815067202.png

    • 技术真材实料,服务尽心尽力

    2. 吐槽

    • 高危漏洞检出率较低

    洞态说明:因为去哪儿部署的是最早一版的洞态,出于稳定性考虑,还未进行版本更新,因此在检测能力上相对新版本会差许多。但洞态会加强研发力度,持续扩大可检测漏洞类型以及高危漏洞的检出率。

    洞态:去哪儿的 IAST 实践亮点在于擅长将 IAST 与自身 Q-SDL 体系的适配,也善于从自身所处互联网行业高流量高并发的特点出发,通过开发负载均衡功能、对 IAST 模块进行调整、扩展开发等手段,将 IAST 的作用发挥到极致,也希望大家都能从去哪儿的安全智慧中找到灵感。 

    扫码添加小助手

    获取洞态产品册

    5651113aec32fba4119799062a097f9e.png

    关于洞态 IAST 

    洞态 IAST 是全球首个开源 IAST ,于2021年9月1日正式开源发布。洞态 IAST 专注于 DevSecOps,具备高检出率、低误报率、无脏数据的特点,帮助企业在应用上线前发现并解决安全风险。自开源发布以来,洞态 IAST 备受开源社区人员和企业的关注,包括工商银行、去哪儿、知乎、同程旅行、轻松筹等在内的上百家企业都已成为洞态用户。


    官网地址:http://dongtai.io

    055828956332f480057a66c15fd3c0dc.gif

    27a0a2b982f2d264792243f58b9d5e16.gif

    展开全文
  • 学习材料owasp主动控制项目SDL 成熟度框架:bsimm & OWASP samm威胁建模:McGraw SARA;威胁建模McGrawSARA什么阶段做安全评估适用范围方法...

    学习材料owasp主动控制项目SDL 成熟度框架:bsimm & OWASP samm威胁建模:McGraw SARA;威胁建模McGrawSARA什么阶段做安全评估适用范围方法论OWASP ASVS缓解机制列表(含公共组件)参考OWASP_Cheat_Sheet_SeriesIEEE安全设计中心(CSD)提出的Top-10-Flaws参考材料

    学习材料

        近日学习了《大型互联网应用安全SDL体系建设实践》,希望各位大神多介绍下工作沉淀的宝贵经验,一起建设应用安全生态,通过学习更加认识到并没有唯一的最佳安全实践,适合各个公司可以落地的就是对的方向,对SDL建设期间选择正确的技术决定工作的重心,安全并非是技术的争论,是非安全的,工程化的,体系化的探索。分享材料最后特意提到了几个材料引用:

    1. owasp主动控制项目

    2. SDL 成熟度框架:bsimm & OWASP samm

    3. 威胁建模:McGraw SARA

    4. OWASP ASVS

    5. 缓解机制列表(含公共组件)参考OWASP_Cheat_Sheet_Series

    6. IEEE安全设计中心(CSD)提出的Top-10-Flaws

    学海无涯,回头是岸。趁着假期学习一下,现记录如下与众读者共勉。

    owasp主动控制项目

    第一项owasp主动控制项目可以参考本公众号之前介绍过的《项目发布 | OWASP Top 10 Proactive Controls V3中文版》,不同于我们熟悉的owasp top10关注主流漏洞排行,主动控制项目关注软件的安全防御构建需求,包括十项:

    C1:定义安全需求(Define Security Requirements)

    C2:使用安全框架和库(Leverage Security Frameworks and Libraries)

    C3:安全的数据库访问(Secure Database Access)

    C4:数据编码与转义(Encode and Escape Data)

    C5:验证所有输入(Validate All Inputs)

    C6:实现数字身份(Implement Digital Identity)

    C7:实施访问控制(Enforce Access Controls)

    C8:保护所有的数据(Protect Data Everywhere)

    C9:实施安全日志记录和监控(Implement Security Logging and Monitoring)

    C10:处理所有错误和异常(Handle All Errors and Exceptions)

        在安全工作中主动控制项目可以作为安全需求确定的checkpoint,安全审计的checklist。主动控制项目会是安全人员和开发人员的共同语言,从安全角度来定义产品做了哪些事可以让“漏洞的利用时间更长”;让开发人员了解:为了实现所负责的产品安全性,需要增加哪些安全任务量。详细的章节各位读者可以访问owasp官网下载阅读。

    SDL 成熟度框架:bsimm & OWASP samm

        再一个是SDL 成熟度框架,可以参考本公众的文章《软件安全构建成熟度模型 (BSIMM) 介绍》,滴滴使用了bsimm8的版本评估出来level2的成熟度,笔者升级了Bsimm9,有兴趣的读者可以搭建环境评估所在单位的成熟度,做为安全能力建设的指标。owasp SAMM适合不以软件开发为主业的公司,疏于维护,不算好用,材料倒是可以看看。

    威胁建模:McGraw SARA;

    威胁建模

        系列材料有《威胁建模系统教程-简介和工具(一)》和《SDL安全设计工具,一款支持多人协作实施威胁建模的微信小程序》。

    McGraw

        是指Gray McGraw,他的个人简介材料可以看下本公众号的文章破框和跨界:一个外国大牛离职后的活法,McGraw也是发明Bsimm的大神。我曾经有幸和他有过交流 :),

    image-20200404192423361

    读者们知道他的邮件签名是什么意思吗?

    SARA

        这个是一个相对较新的软件架构风险分析方法材料,在加拿大军方,法国电信,欧洲汽车安全行业有实际应用,下面将用大量的篇幅介绍SARA。

    什么阶段做安全评估

        DevSecOps的理念是糅合了开发、安全及运营理念以创建解决方案(以后有时间会详细介绍SDL和DevSecOps的区别和联系)。在DEV(Development)和OPS(Operation)中有许多安全的介入点:
        在开发环节可以做的事情有:定义安全需求,引入安全设计原则,对开发人员进行技能培训,使用白盒扫描工具,使用更安全的编程语言(go语言是世界上最好的语言=_=),在迭代中进行安全测试。
        在Operation环节确保安全的配置(配置不当漏洞),进行安全专项审计(众测),应急新发现的安全漏洞(WAF、SRC),检测和审计应用是否有异常行为(hids\nids\rasp\蜜罐\欺骗防御)。
        架构安全风险评估可以在设计阶段实施避免后续开发环节引入的安全体系缺陷,也可以在存量系统已经上线时,评估变更和现有安全风险的影响。

        我们不要仅仅以为安全架构评审仅适用了SDL的安全需求和设计阶段,实际中安全专家入职后的第一件事就是评估现在入网众多核心系统的安全性,目前正在开发的系统并没有那么难搞,可以划分一到三周时间内分别评估多个组件模块,跟随迭代功能一次评估一类,最后形成评估的整体报告。由小到到的好处是容易出成果,当业务发现软件内置的安全越来越完善,合作的安全团队越来越靠谱的时候会容易接受安全的介入,大家一起找到相对安全的平衡点。

    适用范围

        SARA作为一种架构分析框架和SDLC(软件安全开发生命周期)之间是什么关系呢?SARA强调使用组织现有的风险评估流程,为安全架构师使用,需要业务系统架构师,开发、安全、甚至用户视角的参与,专注于快速对目标系统进行评估。SARA流程涉及SDCL除了“安全培训”环节以外的每个流程。从安全实际工作来看,应用安全性提升的阶段分为风险评估,风险环节,再评估闭环三个阶段。SARA只做风险评估的事情。SARA直接包含威胁建模活动和代码审查、安全测试阶段。

    方法论

    1-9个步骤

        下面详细介绍从步骤1到步骤9的实施过程。

    1. 架构访谈及问卷

          收集并基本了解目标的架构相关文档,同业务方的架构师根据架构设计进行访谈和问题review,确定系统关键模块是什么?核心功能有哪些?安全措施是什么?了解系统的关键数据流的流向(可以从GDPR文档中获取一些材料)。必要时登录操作下实际业务,熟悉用户使用的流程。在这一环节形成对关键组件模块的数据流转、安全控制机制、系统内的敏感数据定级三项材料。梳理环节可以有遗漏,但是不能不准确。

    2. 威胁识别

         在该阶段实施威胁建模,可以用微软的Stride或者攻击树模型,注意不要关心业务是否已经有安全加固措施,只需要列出风险即可,风险来源可以是组件历史漏洞、专家经验、同类系统的风险,输出为威胁列表,实施完成的输出材料可以参考本公众号的文章《代码审计-dubbo admin <=2.6.1远程命令执行漏洞》。

    3. 漏洞识别

          这一步是最简单的,使用漏扫工具、白盒扫描、渗透测试的安全验证手段,尽可能提早发现问题,这个节点发现的问题并非是全的,但是起码是当前最紧要的。“未知攻,焉知防”,从攻击小伙伴们获取帮助,对安全架构分析形成更全面的认识。这一步要注意生成安全测试报告时,要和业务团队一一确认责任人和排期,避免后续开发中没有把安全风险纳入开发计划。

    4. 已有控制措施分析

          安全专家必须知道系统目前已经采取的哪些控制措施是有效的,控制措施的列表见《项目发布 | OWASP Top 10 Proactive Controls V3中文版》。这一步识别出来的工作量和业务息息相关,是产品接下来要实现的功能安全。双方分歧最大的是确定安全技术细节,这时候对安全评审人员的要求不是挖洞,而是安全防御方案的设计能力,最好懂开发,了解同类安全措施的漏洞原理和主流防护方案、业界同行的最优实践。

    5. 威胁可能性评估

       业务可以接受的安全建议一定不能是来自“安全迫害妄想症”的臆想,根据上一步输出的已有的安全措施和详细渗透测试报告,可以清晰了解系统已经实现的安全措施的有效性。举个例子是:业务以为启用了md5就是具备足够安全等级的加密,这时候就需要安全专家指出来存在的攻击可能。
          需要于识别到的威胁必须从实际出发去评估发生的可能性。举例来说对于只暴露内网系统,修复的优先级实际上是可以沟通放松的,非得说来自NSA国家级专业团队“精心构造的POC”,有点用自己的最高标准,衡量别人最低要求的意思。

          确定攻击者使用的技能、资源和安全防护措施匹配,指着业务使用的一个流行的加密算法,非得说量子加密可以破解就是抬杠了。安全投入不能无限大,攻击的投入也不可能无限大。

      威胁要结合可能性进行合理评估
    6. 影响分析

          对分析出来的每一项功能探讨如果发生安全问题会带来什么影响,同业务leader沟通安全后果是什么。举例来说在银保证监行业里的业务角度,一个越权身份信息泄露的影响,远比一个XXE的技术漏洞影响高,尊重业务意见,说清安全评估的风险。

    7. 风险确定

          经过以上几步同业务各个方面的关键人员的沟通,确定达成对潜在攻击发生的风险的认知一致。

      攻击可能性评估表
    8. 缓解措施

          风险按照级别和发生的可能性排定风险优先级,制定缓解计划,对业务的缓解或者修复方案进行评估和记录,专业的人干专业的事情。安全负责结果的验收,业务负责方案的制定。如果业务选择接受风险,安全在明确告知风险的前提下也可以接受。

    9. 结果输出

          编写完整报告,说明威胁、风险、级别,安全建议,这一步注意不要忽视低优先的安全风险,让这个文档动起来,避免当时视为低危的风险随着迭代推移风险不断上升。

          最后一定要为建立安全文化而鼓励业务部门,融洽关系,让安全带来正能量,让业务感到安全是为业务提升价值,不是因为安全多了工作量。为下一次安全评审的合作打好基础。

    OWASP ASVS

    ASVS就是Web应用安全评估标准,

    这本书没啥用

    就是这本书,挺薄的,里面是列出来的安全验证checklist。

    V1:架构、设计和威胁建模

    V2:认证

    V3:会话管理

    V4:访问控制

    V5:验证、清理和编码

    V6:存储加密

    V7:错误处理和日志记录

    V8:数据保护

    V9:通信安全

    V10:恶意代码

    V11:业务逻辑

    V12:文件和资源

    V13:API和WEB服务

    V14:安全配置

    缓解机制列表(含公共组件)参考OWASP_Cheat_Sheet_Series

        缓解机制列表(含公共组件)参考OWASP_Cheat_Sheet_Series,简称OWASP CSS,目的是为实施应用程序加固方案的开发者提供一套简单可靠的指南。CSS作为备忘录是owasp 主动控制和owasp ASVS项目的补充。

    接地气可以阅读http://www.toolfk.com/handbook-wizardforcel-owasp-cheat-sheet-zh 项目,介绍了每项cheat背后实际的攻击技术。

    IEEE安全设计中心(CSD)提出的Top-10-Flaws

       是指在一份题为“避免软件安全设计的十大弊端”的报告中,CSD组织希望将重点从发现错误转移到识别设计缺陷,帮助软件开发人员从他们的学习中吸取教训。根据来自Twitter,Google和Hewlett-Packard等各种组织的专家的意见,这份长达31页的报告将建议分为10大类:

    -赢得或给予,但从不假设信任

    -使用无法绕过或篡改的身份验证机制

    -验证后授权

    -严格分开数据和控制指令,切勿处理从不可信来源收到的控制指令

    -定义一种确保所有数据都经过明确验证的方法

    -正确使用加密

    -识别敏感数据以及如何处理

    -始终考虑用户

    -了解集成外部组件如何改变您的攻击面

    -在考虑对象和参与者的未来变化时要保持灵活性

    这个报告也是上面提到的McGraw同志提出来….关于软件安全设计原则,国内鲜少有资料,我将在下次更新为大家介绍,也为自己提供学习的机会。

    参考资料

    https://www.owasp.org/images/f/fd/SAMM-1.0-cn.pdf

    http://www.owasp.org.cn/OWASP_Training/SAMM

     

    SDL已死,应用安全路在何方?

     

    项目发布 | OWASP Top 10 Proactive Controls V3中文版

     

    供应链安全:安全建设中的第三方组件依赖问题

     

    从微软、FB、华为的网络安全备忘录说开去

     

    软件安全构建成熟度模型 (BSIMM) 介绍

    展开全文
  • 安全开发生命周期的管理是保障互联网企业业务正常运营的...互联网公司的SDL必须和现有的CI/CD(持续集成/持续部署)系统(如IDE、Gitlab、Jenkins、JIRA等)集成才能产生较好的效果。SDL的建设必须置于敏捷开发、持...
  • SDL介绍

    千次阅读 2019-01-27 13:32:43
    当我们需要建造一座大楼的时候需要一些步骤,包括选址、设计、建造、验收、装修等等...2、降低残留漏洞的安全风险,SDL可以规范公司web应用的开发流程,指导和协助项目进行安全规划,通过web 应用开发过程中的,需求...
  • 微软SDL(SecurityDevelopmentLifecycle)流程,是一种专注于软件开发安全保障的流程,为了实现保证最终的用户安全,在软件开发各阶段中引入安全和隐私问题。其中主要由以下7部分组成:安全培训(training):推广安全...
  • 1、介绍SDL流程 2、SDL相关工具 2、SDL体系建设介绍
  • SDL2 + OPENGL GLSL 实践

    2022-01-22 18:45:38
    最近,闲来无事,研究了一下SDL2,发现SDL2作为一个开放的平台,确实比较简单,而且在多媒体方面,图像操作方面,跨平台方面确实有优势,实在不行了还有源码可以参考,但也有其不方便的一面,如没有文字显示功能,一...
  • 分享了京东JSRC安全体系建设和SDL方面的经验,以及京东基础安全平台“菊花台”的建设过程
  • SDL DevSecOps 数据安全体系 安全运营的价值与意义 安全运营的衡量标准 安全运营之道:关注落地 安全运营之道:抓主要矛盾 安全运营之道:控制增量 安全运营之道:纵深防御 安全运营之道:关注未知 安全运营之道:...
  • [安全防护]如何通过_SDL_和_SecDevOps_实现软件及应用的原生安全 Android web安全 数据库审计 系统安全 安全开发
  • 论企业如何快速建立SDL流程

    万次阅读 2021-06-09 23:08:00
    今年很多比较大的互联网公司开始试行SDL落地,但是由于相关资料文档有限,导致落地困难,今天这篇文章就旨在讨论一下企业SDL如何快速落地问题,题主落地SDL时间并不是很长,一两年时间而已,但是一样是从零开始,...
  • 3.7.3 因地制宜的SDL实践 1. 重度的场景 对于公司内研发的偏底层的大型软件,迭代周期较长,对架构设计要求比较全面,后期改动成本大,如果安全团队人手够的话,这种场景应该尽量在事前切入,在立项设计阶段就应该...
  • SDL Digital Experience Accelerator ASP.NET MVC Web应用程序 建置状态 开发: 1.8: 先决条件 ... 它的模块化体系结构由框架和示例Web应用程序组成,其中包括所有核心SDL Tridion / Web功能以及用于
  • 信息泄露事件 安全事件分级 高中低漏洞 安全时间应急响应流程 安全是一个过程,需要持续的运营 发现和修复安全问题 防御体系建设和快速响应攻击 SDL落实推动 如何落地 对内 周期性安全扫描 漏洞预警 应急响应 安全...
  • 它的模块化体系结构由框架和示例Web应用程序组成,其中包括所有核心SDL Tridion / Web功能以及用于其他可选功能的单独模块。 该存储库包含DXA框架的源代码,示例Java Web应用程序以及Java的Maven原型。 完整的DXA...
  • 安全开发流程(SDL

    千次阅读 2019-06-05 16:07:15
    0x01SDL介绍 0x02SDL流程框架 0x03SDL实战经验 0x04总结 0x01SDL介绍 安全开发生命周期(SDL)即Security Development Lifecycle,是一个帮助开发人员构建更安全的软件和解决安全合规要求的同时降低开发成本的...
  • BSIMM模型之SDL

    2019-10-21 22:19:30
    安全开发生命周期(SDL)是一个帮助开发人员构建更安全的软件和解决安全合规要求的同时降低开发成本的软件开发过程。 安全应用从安全设计开始,软件的安全问题很大一部分是由于不安全的设计而引入的。安全设计对于...
  • 【应用安全】微软的安全开发生命周期(SDL) 0x01SDL介绍 安全开发生命周期(SDL)即Security Development Lifecycle,是一个帮助开发人员构建更安全的软件和解决安全合规要求的同时降低开发成本的软件开发过程。 ...
  • 推进可信身份认证技术的体系SDL
  • 扯谈SDL(一)

    2020-03-31 08:07:23
    原作者Lancer,原文发表于安全村,原始链接https://www.sec-un.org/%e6%89%af%e8%b0%88sdl%ef%bc%88%e4%b8%80%ef%bc%8...
  • SDL+FFMPEG+VS2017结构图

    2018-04-01 08:06:53
  • 浅谈华为SDL软件安全工程能力

    千次阅读 2020-07-21 20:46:46
    网络安全和隐私保护是公司的最高纲领安全支撑组织架构SDL实践需求设计开发阶段上线前测试时应急响应供应链安全白盒代码扫描目标建设运营层面代码权限管控安全专家参考资料浅谈华为SDL实践 ...
  • 因为对安全和隐私的考虑贯穿了整个软件的开发进程,SDL 能够帮助开发人员写出更“安全”的代码,在解决安全合规需求的同时,也能减少由安全问题带来的损失。 和安全标准一样,SDL 本质上是一个宏观指导性质的框架。...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 2,481
精华内容 992
关键字:

SDL体系

友情链接: IR.rar