i黑马:攻防演练及小规模网络对抗的战术,对抗中的主动防御( 六 )


直接匹配 。 在大规模资产的组织中 , 如果有1day漏洞爆发 , 或者需要针对某一特定漏洞进行探测时 , 整体探测的效率太低 , 最好是能够依靠已有的资产地图直接进行漏洞版本匹配 。 这就需要存留一份完整的漏洞库 , 以及一份完整的资产(包括详细版本)地图 , 并且需要能快速地将两者进行匹配 。
所以在绘制资产地图时 , 要以快速为目标 , 周期性进行高速测绘;再用精准的模式时刻补充、修正和更新;对1day和特定漏洞可以进行资产精确版本的直接匹配 , 以做到第一时间发现和处理可能存在的风险 。
12
组建应急小组 , 实时处理突发事件
应急响应小组 , 在对抗中起到“消防队员”的作用和效果 , 他们应该能够快速处理攻击中后期的各类紧急事件 。 应急响应小组只有由最高责任领导担任总指挥才能发挥其快速响应和贯穿多部门协调资源的效果 。 应急响应小组应该包括总协调人、安全技术专家、安全工程师、各业务接口人等组成 。
在前期 , 应急响应小组应该建立好应急响应流程和安全事件定义 。 关于应急响应的指导性建设 , 可参考GB/Z20985和GB/Z20986 , 相关针对应急响应的各类方案在业界也比较成熟 , 在这里不进行累述 。
在操作层面 , 比较推荐参考YD/T1799 , 其中涉及到对于人员、工具、职责、质量等要求具有很高的操作指导价值 。 同时它对于准备阶段、检测阶段、抑制阶段、根除阶段、恢复阶段、总结阶段的详细阶段描述和操作要求 , 极具指导性和实操性 , 建议根据其要求进行规范和使用 , 制定操作指南 。
13
对抗过程中尽量不要惊动攻击者
在实际与攻击者的对抗中 , 有两个时间 , 尽量不要惊动攻击者:
对攻击行为进行采集和分析时;
对攻击者进行溯源时 。
在对攻击行为进行采集和分析时 , 可以使用旁路流量监视和分析 , 也可以在不惊动攻击者的情况下做其他的检测 。 可以将操作系统、中间件、各类访问日志 , 各类安全设备日志 , 各类流量分析结果统一汇总到非DMZ区或者业务区的分析平台进行分析 , 将攻击事件进行关联 。
在进行攻击者溯源时 , 使用的JS、钓鱼等技术和手段 , 应该尽量加密、混淆、仿真、伪装和反溯源 , 尽量不要引起攻击者怀疑 , 尽量提高其分析难度 , 尽量使其难以进行反溯源 。
在抓取足够数据时 , 立刻进行封堵、反击等操作 , 使其措不及防 。
14
只要有业务系统变更或模块升级 , 就应进行安全测试
业务系统经常会有变更和模块升级 , 包括网络架构、Web业务系统、APP、工控系统、小程序、各类接口等等 , 只要有变更 , 或者某些功能模块的升级 , 都应该对变更部分进行安全性测试 , 以保证新上线的功能没有安全隐患 。 更好的办法是在它们集成到现有业务系统之前 , 在测试阶段就进行安全性测试 。 但是测试环境和真实环境仍然是有差别的 , 有时在测试环境中没有发现问题 , 在真实环境下会出现问题 。 所以最好是能够在正式上线前的测试环境和正式上线后都进行一次安全性测试 。
另外 , 应该在新系统或者新功能设计时就考虑到安全性 , 并将其设计在其中 。 如果有可能 , 建议建立统一威胁和漏洞管理 。
15
溯源能力越强 , 自查和修补措施越完善 , 被攻破的可能性越小
在网络对抗方案设计阶段 , 应该考虑到以上各部分的内容 , 考虑得越详尽 , 越贴合业务场景 , 约有实操性 , 对抗能力越强 。
i黑马:攻防演练及小规模网络对抗的战术,对抗中的主动防御
文章图片
在实际环境中 , 往往要建设一个完善的主动防御体系 , 是需要分阶段、分步骤进行的 。 如果之前没有进行过这方面的建设 , 我建议按照如下步骤考虑 , 这里包括了对于成本、实施难度、立竿见影的效果等多方面的因素: