从黑客攻击聊聊事件响应与事件管理( 二 )

  • 拒绝服务(Denial of Service,DoS),主要体现在攻击者迫使目标系统的资源(如:处理或存储能力等方面)不可被访问与使用、或完全无法受理正常服务请求 。例如,各种 SYN 泛洪攻击、TCP 复位攻击、缓冲区溢出等都属于此类威胁 。对此,我们可以通过采用安全协议,完善配置,增加检查等方式,来予以防范 。
  • 特权提升(Elevation of Privilege),主要体现在攻击者在系统管理员不知情的状态下,通过普通用户获得特殊访问权,进而破坏目标系统 。例如,用户代码超越缓冲区,以更高权限执行敏感操作 。或是由于访问检查的缺失或不当,导致攻击者未经授权地运行了可执行文件等 。
  • 尽管 STRIDE 是目前最为流行且有效的威胁建模与安全设计框架,不过如果您觉得它有些陈旧的话,则可以参考最新的零信任网络(zero trust networks,ZTN)安全模型 。它秉承的是“从不信任,始终验证”的概念,即:在任何用户、资源或资产都是不可信的前提下,通过消除隐含的信任关系,并不断验证每个阶段的交互过程,来保护目标组织和应用系统 。
    无论是被部署在云端,还是在本地,零信任网络作为一种持续评估和验证的关键性流程组件,可以在检测过程中,为响应团队提供有关的可疑访问请求、以及事件本身的详细信息 。我们可以通过如下方面对各类网络攻击,做出及时响应,并最大限度地减少损害 。
    • 假设违规 。由于凡事都不可信,因此我们能够从网络中已存在着攻击者的角度出发,更加专注于阻止各种违规行为 。
    • 完整的可见性 。我们能够通过管理各种凭证、访问、操作、端点环境、以及基础设施,来监控用户请求所对应的身份、设备、应用和数据,这四种元素的详细信息 。而在验证过程中,一旦发现任何异常的访问尝试,响应团队都能准确地关联到特定的实体、应用和数据上 。
    • 自动化响应 。由于处于零信任状态,因此有待检查的节点会更多 。我们往往需要实施自动化的检测与缓解手段,并通过事件关联来剔除误报,并自动更改网络访问规则,进而构建比手动响应更为有效的反应机制 。
    当然,没有一种完全模型能够完美到“团灭”所有的威胁、或“包治百病” 。我们应当根据实际情况,选用、调整或自定义某一种、或混用各种安全模型的用例,通过缩小信任区域范围,制定出更快、更有效的响应计划 。
    事件严重级别?光有定性的识别模型显然是不够的,我们在实践中还需要有定量的指标等级,以便滤除“噪声”,界定和分析事件 。
    从表面上看,严重性高的事件通常需要快速的响应,但是实际情况并非一成不变 。由于在事件响应的过程中,我们往往推崇的是“快速生效” 。因此,对于某些低严重性事件而言,如果它们需要调用的资源较少,能够立竿见影,起到迅速遏制事件在范围与程度的效果,那么我们就可以将其视为高优先级的处置目标,予以快速修复 。可见,事件的严重程度并不能完全决定了事件的优先级,我们需要从业务的角度,多方面综合考虑 。
    当然,最为稳妥的方法应该是:以事件对于业务的影响程度,来界定严重性级别 。无论是服务级别目标(Service Level Object,SLO)也好,还是服务级别约定(Service Level Agreement,SLA)也罢,它们都直接影响着我们去确定安全事件的严重性与优先级,并且会影响到如何配置人员与资源,以及是否按需升级响应等级 。在此,我以一个 App 的页面平均加载时间为例,向您展示严重性与响应的关系:
    严重程度
    状况
    客户影响
    涉及到利益相关方
    1
    页面无法加载
    客户无法使用应用服务违反SLA
    响应团队执行应急方案,各部门展开排查,告知管理层
    2
    页面加载速度慢200%
    服务响应极慢,客户失去使用意愿
    应急响应团队协同运维团队排查,并向客户发出警告
    3
    页面加载速度慢50%
    服务响应缓慢,客户产生抱怨
    运维团队排查
    4
    页面加载速度慢1%-10%
    大部分客户未注意到
    将事件录入事件管理系统,但无需立即升级或发出警告
    通常,我们应当事先制定好一个包含了事件影响范围和程度的等级关系矩阵 。运维人员和应急响应人员可以将收集到的指标参数,对应到事先明确定义好的取值范围中,进而通过客观且公式化结合方式(或是相乘、或是相加),来确定其严重性 。


    推荐阅读