「黑客与极客」对抗中的主动防御:攻防演练和小规模网络对抗的战术分析( 六 )


「黑客与极客」对抗中的主动防御:攻防演练和小规模网络对抗的战术分析
本文插图

对于信息资产的测绘 , 应该兼顾以下三点:
第一、快速 。 快速绘制出资产 , 对于前期的准备 , 以及定期的大规模更新有极大的帮助 。 大型组织往往资产数量能达到几万、几十万、甚至上百万 , 涉及到的公网和内网网段能达到几个B段(一个B段的资产探测数量在6万以上)、甚至几个A段(一个A段的资产探测数量在1600万以上) , 要对常用的服务进行探测 , 则要在此探测基础上乘以几十左右 。 对于海量资产的快速测绘 , 才能绘制出资产地图框架 。
第二、精准 。 如果说快速绘制是1:100000的地图 , 那么精准绘制就是1:500 , 快速绘制的地图更适合做决策 , 精准绘制的地图重在操作层面 。 目前大部分用于快速绘制的网络测绘产品都是基于zmap等底层开发的 , 它们在快速的同时 , 受到网络波动和配置等影响 , 会在精准性上有局限性 , 所以还要考虑使用nmap等可以进行真实链接的产品 , 甚至是依靠P0F、suricata(部分功能)这类能够进行被动测绘的自动化工具或者产品;
第三、直接匹配 。 在大规模资产的组织中 , 如果有1day漏洞爆发 , 或者需要针对某一特定漏洞进行探测时 , 整体探测的效率太低 , 最好是能够依靠已有的资产地图直接进行漏洞版本匹配 。 这就需要存留一份完整的漏洞库 , 以及一份完整的资产(包括详细版本)地图 , 并且需要能快速地将两者进行匹配 。
所以在绘制资产地图时 , 要以快速为目标 , 周期性进行高速测绘;再用精准的模式时刻补充、修正和更新;对1day和特定漏洞可以进行资产精确版本的直接匹配 , 以做到第一时间发现和处理可能存在的风险 。
十二、组建应急小组 , 实时处理突发事件
应急响应小组 , 在对抗中起到“消防队员”的作用和效果 , 他们应该能够快速处理攻击中后期的各类紧急事件 。 应急响应小组只有由最高责任领导担任总指挥才能发挥其快速响应和贯穿多部门协调资源的效果 。 应急响应小组应该包括总协调人、安全技术专家、安全工程师、各业务接口人等组成 。
在前期 , 应急响应小组应该建立好应急响应流程和安全事件定义 。 关于应急响应的指导性建设 , 可参考GB/Z 20985和GB/Z 20986 , 相关针对应急响应的各类方案在业界也比较成熟 , 在这里不进行累述 。
在操作层面 , 比较推荐参考YD/T 1799 , 其中涉及到对于人员、工具、职责、质量等要求具有很高的操作指导价值 。 同时它对于准备阶段、检测阶段、抑制阶段、根除阶段、恢复阶段、总结阶段的详细阶段描述和操作要求 , 极具指导性和实操性 , 建议根据其要求进行规范和使用 , 制定操作指南 。
十三、对抗过程中尽量不要惊动攻击者
在实际与攻击者的对抗中 , 有两个时间 , 尽量不要惊动攻击者:
第一、对攻击行为进行采集和分析时;
第二、对攻击者进行溯源时 。
在对攻击行为进行采集和分析时 , 可以使用旁路流量监视和分析 , 也可以在不惊动攻击者的情况下做其他的检测 。 可以将操作系统、中间件、各类访问日志 , 各类安全设备日志 , 各类流量分析结果统一汇总到非DMZ区或者业务区的分析平台进行分析 , 将攻击事件进行关联 。
在进行攻击者溯源时 , 使用的JS、钓鱼等技术和手段 , 应该尽量加密、混淆、仿真、伪装和反溯源 , 尽量不要引起攻击者怀疑 , 尽量提高其分析难度 , 尽量使其难以进行反溯源 。
在抓取足够数据时 , 立刻进行封堵、反击等操作 , 使其措不及防 。
十四、只要有业务系统变更或模块升级 , 就应进行安全测试
业务系统经常会有变更和模块升级 , 包括网络架构、Web业务系统、APP、工控系统、小程序、各类接口等等 , 只要有变更 , 或者某些功能模块的升级 , 都应该对变更部分进行安全性测试 , 以保证新上线的功能没有安全隐患 。 更好的办法是在它们集成到现有业务系统之前 , 在测试阶段就进行安全性测试 。 但是测试环境和真实环境仍然是有差别的 , 有时在测试环境中没有发现问题 , 在真实环境下会出现问题 。 所以最好是能够在正式上线前的测试环境和正式上线后都进行一次安全性测试 。


推荐阅读