北京网站seo技术厂家,招商网站设计,seosem是什么意思,网站设计中的js应急响应流程及思路
一#xff1a;前言 对于还没有在项目中真正接触、参与过应急响应的同学来说#xff0c;“应急响应”这四个字见的最多的就是建筑工地上的横幅 —— 人人懂应急#xff0c;人人会响应。这里的应急响应和我们网络安全中的应急响应有着某种本质的相似…应急响应流程及思路
一前言 对于还没有在项目中真正接触、参与过应急响应的同学来说“应急响应”这四个字见的最多的就是建筑工地上的横幅 —— 人人懂应急人人会响应。这里的应急响应和我们网络安全中的应急响应有着某种本质的相似但却有些许操作的不同。 网络安全中的应急响应我个人的将其分为两种一种是事前响应 —— 即未雨绸缪做到防患于未然将灾难性事件扼杀在萌芽之中另一种就是事后响应 —— 即亡羊补牢灾难性事件发生之后将损失降到最小。对于网络安全而言我们所遇到的大部分应急响应的情况都是事后响应导致这个情况主要是因为我国网络安全现状下企业安全投入与产出效果之间的矛盾以及网络安全事业起步晚、整体网络安全意识不高等。对于企业而言对网络安全的投入基本是合规驱动满足法律法规要求和监管要求和事件驱动安全事件加之我国网络安全整体意识不强不少企业基本就是实行出了问题再弥补的被动式防御措施。因此本文着重讨论事后响应的流程及思路。
二应急响应流程及思路
A事前响应 听到事前应急响应不少同学肯定心里在想事件没发生何来应急如何响应笔者怕不是还没睡醒吧如此不专业。在这里笔者保证在和同学们分享此篇技术文章的时候是前一夜睡了一个好觉还是自然醒。 网络安全中的事前应急响应简单的概括为就是企业因某些安服服务驱动因素事前向安全公司购买相关蓝队安服服务或攻防演练服务比如风险评估服务、人员安全意识培训服务、进行安全巡检服务、制定安全运营管理计划服务、举行应急演练服务、攻防演练服务、进行数据安全备份等以此来提前对未发生的安全事件做出防范措施。
B事后响应 而对于事后应急响应不少同学在不同的论坛、文章中也看见过。笔者将事后应急响应的流程归纳为事件确认 —— 事件抑制 —— 事件处置 —— 事件分析 —— 编写报告 —— 事后跟踪。
一事件确认对已经发生的安全事件进行确认是真实攻击还是设备误报等定性分析处理事件所需要的资源支持。
1确认安全事件的类型、评估事件的影响范围。
2安服客户情绪确定客户面对此次安全事件的真实需求和痛点。安全事件发生之后客户可能存在焦急、紧张的情绪作为技术人员需要用自己的专业性来安抚客户情绪引导客户确认面对此次安全事件的真实需求有利于技术人员快速、准确的处理安全事件。
3根据经验定性判断处置此次安全事件所需要的资源支持设备资源、人员资源、时间资源等等并形成工单或报告提交给客户。这个举措可以起到安抚客户情绪并体现我们作为技术人员的专业性
二事件抑制确认为安全事件之后为了防止攻击者将攻击面扩散需要在一定程度上对事件进行攻击抑制。 在事件处置之前我们可以根据事件的严重性制定相应的应急措施并根据客户的业务情况进行具体的事件抑制操作。
1可中断业务即发生严重安全事件时客户运行的业务系统可以暂时中断修复。
1关闭在此次安全事件中被攻击失陷的业务系统并告知客户可向用户发布系统暂时维护的通知安抚用户。
2断开被攻击系统的网络或关闭被攻击利用的服务。
3禁止登录或删除被攻击的系统账户。
2不同中断业务即发生严重安全事件时客户的业务系统不能中断运行。
1修改被攻击的系统账户密码。
2根据被攻击的具体情况重新配置安全设备的安全策略。
3设置源IP白名单。
4对攻击感染的设备或系统进行隔离处置。
三事件处置在对攻击系统进行隔离或对攻击进行抑制之后需要对事件攻击进行具体的处置。
1清除被攻击系统中的病毒、木马、恶意程序等。可以使用清理工具进行检测和清理内存和进程检测工具Process Hacker启动项监控工具Autoruns文件、恶意代码检测工具Pchunter杀软EDR等。
2清理Web站点中存在的木马、暗链、挂马页面等。可以使用D盾、河马等进行木马、病毒检测和查杀。
3恢复被攻击者篡改的系统、设备配置删除攻击者创建的账户。
4删除异常的系统服务清理异常进程。
5若业务中断需要重启业务。
四原因分析查找并分析此次安全事件的攻击链利于预测、阻止和应对潜在的攻击。
1进行威胁情报收集确定攻击IP了解攻击者的基本情况利于后续的溯源工作。
2对系统日志、Web日志、安全产品相关日志、网络流量日志等进行分析理解攻击者的入侵手法调查此次安全事件的原因。
3根据客户需求对攻击者进行溯源。
五编写报告根据此次安全事件的具体情况编写《xx事件应急响应报告》
1事件处置完成之后根据此次安全事件的情况编写安全报告描述安全事件的具体情况、处置过程、处置结果以及对事件的分析并向客户提出整改建议、安全产品加固建议。【此处作为安全厂商的安全人员应该着重对待 —— 商机】
六事后跟踪对此次安全事件进行跟踪定时询问客户系统安全情况。 一般的文章或论坛中对于应急响应的流程并没有这一步作为技术侧人员认为在《xx安全事件报告》提交、通过之后此次事件就算结束。但笔者认为事后跟踪却是另一个故事的开始。 我国的安全服务现状是重产品轻服务安全企业的收入主要还是依靠安全产品侧。虽然现在很多厂商想极力改变这种现状但至少目前我国安全服务还是重产品轻服务。因此在对于应急响应的流程中笔者加入了最后一环事后跟踪。 事后跟踪一方面可以复盘发现在安全事件应急响应中存在的不足和问题利于安全企业进行改进提高另一方面有助于事后监测客户系统安全情况更重要的是给客户一种专业、负责的感觉。同时事后跟踪可以增强企业与客户的粘性帮助客户明确企业在安全体系建设中的缺陷利于帮助客户企业提高安全运营体系建设降低、甚至杜绝此类安全事件再次发生的可能。
