SDL 推广中常见问题
本文最后更新于 91 天前,其中的信息可能已经有所发展或是发生改变。
内容目录

开发 & SDL

SDL 基本流程

SDL 安全开发的意义是什么?

SDL 是将传统开发与网络安全整合后的一个管理模式。
目的是从网络安全的角度指导软件开发的过程,从而保证系统安全性。
意义是从根源上防范和避免系统安全问题,尽早发现,提前解决。
众所周知,随着时间的推移,解决问题的成本是越来越大的,而 SDL 就是将安全问题左移,在开发阶段规避安全问题,从而降低后期系统在安全上的维护成本。

系统安全应该是由安全部门主要负责,而推广安全开发规范的确减少了安全人员的工作量,但大幅度增加了开发人员的成本,这合理吗?

首先,系统安全并不是只由安全部门来负责的。如果发生网络安全事件,损失的是公司的利益而不是某个部门某个人,而公司的利益应该是所有部门共同维护的。
再者,作为开发部门,是由责任有义务为自己所开发的产品的安全性负责的,而安全只是起到一个引导、监督的作用。安全开发规范的遵循,降低了网络安全漏洞的风险,降低了安全事件的概率,同时也降低了安全部门、开发部门等到系统上线后再发现漏洞、造成损失、紧急修复的一系列成本。

我们的产品有 WAF 防护,为什么还要做 SDL?

WAF 是第三方产品,只要是三方产品,就必然会有两个因素需要考虑:成本、安全性。
如果我们将网络安全完全依赖于 WAF,那一旦 WAF 产品被绕过,后续将没有任何防线,攻击者将如入无人之境。
防护,不应该存在任何侥幸心理,我们要做的也不仅仅是在系统上线之后采用 WAF 等三方设备防护,而是要在整个系统的的需求确定、功能开发、配置部署、上线运行、后期维护等所有的阶段全部进行安全加固,这样才能使我们的产品更加安全。
举个例子,国家反诈中心 APP 是国家公安部联合安全大厂研发的用来从识别和拦截诈骗电话的应用,但是即使安装了反诈中心,为什么依然会收到诈骗电话,为什么依然会有大量的人被骗?
拦截,从来都不是防护的核心措施,它只是一个降低风险的手段,防护依然是要从根本上解决问题的,拦截也只是拦截那些公开在互联网上,具有明显特征的攻击流量,而攻击者精心构造的攻击代码是有很大的概率绕过特征识别的,而一些特征不明显的攻击代码,也很容易被误拦截或者漏拦截;
再者,WAF 也仅仅是从流量层拦截,对于非流量层攻击,或者大数据流攻击,真实 IP 攻击等等都是无法拦截的,并且 WAF 产品是需要一定的成本的,每接入一个域名,可能就需要一笔支出,所以在正常情况下,我们只会将一些核心业务接入 WAF,而并不会将所有的域名都接入,以此来降低成本,那么这些未接入 WAF 的产品,就成为了网络攻击的脆弱面,完全裸露在互联网上,通过边缘资产横向移动入侵主资产,也是攻击者入侵常用的手段之一。
SDL 是从设计阶段、编码阶段一直到最终上线阶段全程把控并加固,从根本上规避安全风险,WAF 只是防护绝大部分基于流量的网络攻击行为,减轻服务器的压力,而那些穿透 WAF 的漏网之鱼,就需要我们自己来防护了。
退一步讲,如果不做 SDL,只依赖于 WAF 等安全产品,那如果 WAF 被绕过,攻击行为达到了我们系统,我们大概率只能干着急等待三方厂商升级安全产品;如果有 SDL 记录,我们就可以在最短的时间内确定漏洞位置并打上临时补丁缩小危害影响范围。

SDL 一定能保证我们的系统安全吗?

安全无绝对。没有任何一个流程、任何一个产品、任何一个团队敢 100% 的保证绝对安全。即便是顶尖的安全公司(如奇安信、长亭等)的安全产品也是在被不断的攻破、不断的升级中迭代成长的。
也正是因为如此,所以才会有 SDL 的推动,SDL 旨在跟踪加固软件开发的全流程,在每个阶段都争取最大限度的减少安全风险,从而使最终产品的安全风险降低到最低。

是否所有的系统都要遵循 SDL 流程?

理论上来说是建议所有系统都遵循的,但实际执行过程中,由于人力时间等成本问题,很难实现,所以,我们通常会将系统分为 4 个等级:

  1. 核心业务互联网系统(必须严格遵循)
  2. 非核心业务互联网系统(必须遵循,可适当放宽整改期限)
  3. 核心业务内网系统(建议遵循)
  4. 非核心业务内网系统(可以不遵循)

如果业务需要紧急上线,而 SDL 需要一定的延期,该如何处理,是否还可以继续及时上线?

具体情况具体分析。
理论上来说,安全的优先级是要高于业务的。因为一个不安全的产品如果上线,不仅可能会给公司带来风险,也会给用户带来一定的不安全因素,在目前网络安全已经立法的情况下,如果造成损失很可能受到网信办的处罚,得不偿失。
但实际情况下,毕竟业务是公司运转的核心,所以会根据实际情况对风险类型、业务类型、影响范围、应急方案等多个维度展开评估再做决定。
但是,即使评估结果允许业务先上线,也应该以最高优先级继续 SDL 其余步骤并在最短的时间内保证 SDL 闭环。

RASP 和 IAST 在 SDL 中起什么作用,意义是什么?

RASP 是一种运行中应用自我保护技术,它的原理是使用 hook 关键函数的方式,实时观测程序运行时的内部情况,根据上下文精准识别攻击事件并给予实时阻断,使程序具备自我保护的能力。
相比于 WAF, RASP 通过特征规则、上下文语义及数据模型等大幅度提升了告警准确性,并且可以主动发现未知安全威胁,清晰的还原出代码级别的攻击调用栈,对漏洞复现与漏洞修复有极大的帮助。
RASP 还能够对应用打虚拟补丁,对官方尚未修复的漏洞,或者官方提供了修复方案,但业务不容许系统重启的情况下,其热修复机制可以对漏洞及时止血,大大降低漏洞逃逸时间。
RASP 在 SDL 中,通常集成于开发阶段与测试阶段,利用其持续监控扫描的特点,精准且及时的识别安全漏洞,其攻击路径还原的功能也可以帮助安全和开发人员更快的定位和修复漏洞,极大的节省人力成本。

安全开发规范中某些规范有争议。注入类攻击方案、权限管理这些都比较好理解,但是像输出校验、输入校验、文件安全等模块中很多条目觉得意义并不大,比如输入字符不校验就一定会导致被攻击吗?打印异常信息会造成攻击吗?文件安全虽然没有检查后缀名,但是后端处理的时候只解析了 excel,如果传别的后缀也无法解析,虽然不检查但应该也无法攻击利用吧?

  1. 注入攻击,权限管理相关的规范比较好理解,是因为这些模块的漏洞非常明显,如果不遵循规范,可能会直接导致利用,利用难度极低,所以这些往往也直接被定义为高危;
  2. 漏洞利用并不是单独从某一个点去利用的,大多数情况下是利用多个点去进行组合攻击,简单来说,单独的异常信息回显、堆栈信息回显,可能并不会造成安全问题,反而对于开发人员来说更加方便定位问题所在。这也是开发与安全比较具争议的一个点,但是根据真实的安全事件来分析,异常信息回显是目前网络攻击行为利用率最高的突破口,没有之一,从异常信息回显中,攻击者可以收集到大量的系统信息,如:操作系统类型、系统框架、版本、持久层框架类型及版本、方法调用链、输入的特殊字符是否被解析、数据库的类型与版本、某些实体的字段名、数据库的表名库名、配置文件路径等等,从而进一步调整 payload 利用、使用其他 nday 漏洞、或者从其他接口、子系统中进一步利用等。
  3. 输入类型不校验不一定会导致攻击,文件后缀不校验也不一定会导致攻击。但是规范本身就是具有普遍性的,而不是针对某一个特殊情况,如例中后端只解析 excel,确实验证后缀名的意义不大,但这属于特殊情况,不具有通用性,标准是需要统一遵循的。类似的如果在实际场景中,是可以延期或者降级处理,不影响系统上线,但后期还是要做处理的。
  4. 文件安全这一块再补充一点,即使文件目前全部存储在单独的服务上,不会造成 getshell 等高危风险,但是为了防止后期业务变更导致更换存储方式等问题,也是需要遵循安全开发规范的。因为 SDL 安全开发的意义就是从根源上(开发的过程中)尽早的去发现并避免安全问题,而且节省后期安全修复的成本。而不是当下因为一些特殊场景而放弃某条规范,等到万一后期场景切换了,再返工重新对每个系统逐一做加固,这样就失去 SDL 安全开发的意义了。

公司 & SDL

SDL 的详细流程都包含哪些步骤?

更新一个流程图,更加详细:https://www.yuque.com/u2164633/bkdm2z/rk81ra6pn8wqd8hd

SDL 中应该优先做的都有哪些步骤,分别需要多少人力成本?

需要优先做的有以下几个步骤:

  1. 安全开发规范制定(无规矩不成方圆)
    1. 2 ~ 3 人
    2. 至少 1 人同时熟悉安全与开发,拥有代码审计能力
  2. 安全开发宣讲、推广(阐明 SDL 建设的意义、目的)
    1. 可针对业务线,每个业务线 1 ~ 2 人即可
  3. SDL 流程推广(针对系统上线流程,将安全检查相关步骤融入)
    1. 同上
  4. 渗透测试 & 代码审计(作为 SDL 中最核心的两个步骤,优先实施)
    1. 渗透测试 2 人以上
    2. 代码审计 2 人以上
    3. 渗透 & 代审此类工作逻辑性太强,单人实施难免会有思路局限性导致漏审漏测,所以通常都是至少 2 人同时进行,互补审&测结果。

SDL 详细的推广计划(在人力不是很充足的情况下,先推广核心的流程)?

  1. 安全开发规范制定
    1. SDL 作为安全开发,是系统开发和网络安全的组合,所以必须得制定统一标准,遵循相应的安全开发规范,才能顺利开展后续的渗透测试、代码审计之类的工作,否则后续必然会出现开发与安全之间的矛盾。‘
  2. 漏洞全生命周期管理平台
    1. 跟踪漏洞的生命周期
    2. 归档漏洞的处理结果
    3. 分析统计漏洞出现的频率及原因
    4. 版本的测评机制
  3. 渗透测试
    1. 在 SDL 流程中,渗透测试与代码审计是同等重要的,也是作为 SDL 过程中最核心的两个流程。
    2. 在人力不充足的情况下,建议首先推广渗透测试。理由
      1. 代码审计的工作对人能力和精力要求更高,结果不是很明显(代审更针对的是潜在威胁)
      2. 渗透测试实行和调整起来更加方便,结果比较明显(渗透更针对可以造成实质危害的漏洞)
学海无涯,回头是岸。 --- hola
暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇