安全服务的一些思考

总结一些安服遇到的问题及思考

(一)安全服务小组的主要工作

(1)应急响应和取证溯源。
(2)对客户中出现的网络威胁进行分析和处置。
(3)配合公司自有产品发现威胁和解决网络安全问题。
(4)关注重大威胁事件,跟踪并能及时将解决方案同步到客户侧。

(二)安全服务小组在现实中的任务

1)网络安保 :在国家重大活动中提供的安保服务,分两种;
由公安部牵头,支撑单位配合的无偿安保任务。在活动期间派驻一名工程师7*24小时驻守,不需要主动接管安保单位的网络安全。发生安全事件,而安保单位自己的安全团队不能解决时,我方需介入并上报CNCERT;
另一种为甲方购买了重大活动安保服务。我方将按合同派1到2名工程师到现场值守,需要主动利用网络安全设备来发现问题,解决问题。

2)会议交流:为宣传文化或由主管部门组织的行业专题交流。

3)应急响应:客户网络遭受攻击,派工程师前往阻止网络攻击,恢复系统正常运行,完成后期加固溯源。

4)项目支撑:支持其他部门项目,主要为销售、售前、售后、研发。

5)威胁分析:样本、流量,安全日志等分析工作。

6)产品巡检:按合同,依据公司产品提供安全检查服务,完成巡检报告,配合客户处理威胁。

7)培训项目:主要为恶意代码分析方向、安全意识、渗透、加固等培训。

8)技术研究:个人技术提升或项目技术研究。

9)研发项目:平台搭建,工具编写等研发。

10)其他项目: 不在以上9类的。

(三)按照任务和规划要求小组具备以下能力

(1)样本分析能力,主要是快速鉴别的能力。
(2)网络流量分析能力
(3)综合攻击场景认知能力
(4)网络安全设备日志分析能力
(5)客户有效沟通能力。
(6)重大项目交付能力
(7)态势感知平台化服务能力



以下是面对各任务下的思考

(一)应急响应思考(描述问题比解决问题重要)

1、负责人接听客户应急电话,询问情况,初步判定事态,组建应急团队。
      询问的问题包括:
      发现问题的现象是什么样的?
      出现问题的时间?
      做了什么处理?
      是否影响业务、能否断网?
      问题机器是什么系统?
      能否远程?
 远程指导客户意见:不影响业务的情况下断网,启用备份;不影响业务情况下,安装杀毒软件全盘查杀;保留现场,等待工程师取证。

2 、现场
要求管理员陪同全程参与、以将业务恢复正常为主要目的、充分了解网络架构完 成溯源和加固。

目前在实施过程中较为突出的问题有:安服人员对linux服务器应急经验薄弱、网络设备日志没有重点。

(二)样本分析思考
1、查看md5值,将ms5值或文件名在威胁情报平台检索或google。
2、动态监控,查看文件行为,网络行为。将监控到的文件路径、注册表、网络地址等在威胁平台关联。
3、脱壳后,静态查看字符串,在威胁平台关联字符串。
4、调试分析。
注意关键点的截图。

目前问题:漏洞利用类样本分析难度较大,感染式病毒修复、批量样本分析,勒索解密。

(三)基于公司安全产品的巡检工作思考

了解客户的关注点,有些客户关注威胁,有些希望大事化小。

客户关注重点及有价值的威胁:

(1)监管部门事件通报。
(2)网页篡改
(3)服务器故障
(4)数据泄露

甲方可能面临的高级威胁场景:
(1)个人U盘带到内网的高级攻击。
(2)以员工个人PC作为跳板的横向攻击。
(3)员工点击网络链接,利用浏览器0day的攻击。
(4)员工邮件附件文档或可执行程序的攻击。
(5)员工账号信息获取转入下一环节的攻击。
(6)服务器弱口令用户账户爆破攻击。
(7)服务器组件0day漏洞利用攻击。

某些高级威胁场景现象:

(1)深夜时段连接通信。
(2)服务器主动外联IP。
(3)文件传输量大,数据包大,引发的威胁场景。
(4)ddos拒绝服务攻击。
(5)主动防御拦截的威胁
(6)沙箱前置检出的未知威胁的威胁场景。

(四)小组其它规划

(1)在遇到疑难安全事件,无法判定时,组织其它安全小组一起参与威胁研判,这一环节可以理解为:专家会诊
(2)召开安全例会,每周一次,或每日早晨开始,对工作进行安排,对自己处置的威胁在会议中通报审核。
(3)案例分享,面对较为重要的事件,比如新出现的一些攻击手法,做报告分享。

(五)企业应该做的

  (1)做好邮件防护
    (2)做好U盘防护
(3)安装最新漏洞补丁
    (4)终端杀毒,主动防御

原文地址:http://blog.51cto.com/antivirusjo/2091970

时间: 2024-08-29 16:14:37

安全服务的一些思考的相关文章

从零开始的Devops-通用服务平台解决方案思考

通用服务平台解决方案思考 标签(空格分隔): 工作 分析我们的业务 如何复用服务端代码和相关功能. 如何快速开发h5,iOS,安卓,小程序等. 如何分解和规划不同通用功能的边界. 如何定义通用功能的接口. 如何避免重复建设. 如何避免技术重复规划. 系统之间缺乏集成协作标准. 目标 支持多平台:h5,iOS,安卓,小程序等 提高可复用性和可靠性:不用重复开发短信验证,登陆,注册,推送等功能. 汲取成熟:规范接口定义,汲取成熟的方案. 各个模块解耦:防止复用代码,需要同时大量复用依赖库和相关代码.

[服务器架构]微服务的深入思考

微服务有且仅有一种非常专项的功能,通过远程API来提供系统其余功能.举个例子:试想一下仓库的管理系统,这样的系统中微服务可能提供的一些功能有: 接收库存 计算新的库存该存到什么地方 计算在仓库内将库存运往正确放置点的路线 为仓库员工分配运送路线 接收订单 计算仓库内指定一组订单的拣货路线 为仓库员工分配拣货路线 以上这些功能(可能还会有更多)都是由单个微服务实现的.每个微服务都有单独的运行线程,并且可以独立于其他微服务进行部署.同样每个微服务都有自己的专用数据库,尽管每个微服务都会与其他微服务协

对于微服务的一点思考

公司说我们的开发方式是敏捷开发,实际上只是使用了一些敏捷开发的方法,只有遵守敏捷开发的价值观和原则,才能算是敏捷开发.微服务也是一样,不是说拆分成多个服务去部署,就叫做微服务.也不是采用市面上常用的微服务框架,就是微服务了. 上面这段话是我对微服务的简单理解. 随着公司业务的发展,部门领导要求其中一个业务量比较大的要做负载.只给了一周的时间,包括开发和自测.因为时间比较紧,采用了最简单快捷的处理方式:缓存统一放Redis,起了一个辅助项目来做公共和定时器等方面的处理. 此种方式基本把压力推到了R

如何像企业家一样思考

仅把自己当作一个企业家来思考并不会给你带来太多的好处.要想从中收获更多,你必须明白如何思考. 设想一下,一个企业要不断地向前发展,应该怎么做?不难发现: 首先,企业要有一个产品或服务.对大多数软件开发人员来说,卖的就是开发软件这项服务: 企业需要持续不断地改进和完善自己的产品.这一点对开发人员来讲要做到以下几点: A. 专注于你正在提供怎样的服务: B. 想方设法提升你的服务: C. 思考你可以专注为哪一特定类型的客户或行业提供特定的服务: D. 集中精力成为一名专家,专门为某一特定类型的客户提

《31天成为IT服务达人》--做事篇(第四章)之如何找目标

?? 前面介绍了什么是IT服务.以下几章将介绍IT服务该怎么做.在聊怎么做之前.想起几句流行的告白和准备入行IT服务事业的朋友共勉. 当你的才华 还撑不起你的野心时 就应该静下心来 学习 --- 当你的能力 还驾驭不了你的目标时 就应该沉下心来 历练 --- 梦想 不是浮躁 而是沉淀和积累 --- 仅仅有拼出来的漂亮 没有等出来的辉煌 --- 机会永远是 留给最渴望的那个人 --- 学会 与内心深处的你对话 问问自己 想要如何的人生 --- 静心学习.耐心沉淀 送给全部的朋友和我自己! 好.言归

智能家居热潮背后的冷思考

随着谷歌.苹果.三星等巨头的涉足,国内海尔.美的.京东.阿里等传统家电厂商及互联网企业的涌入,一时间智能家居成为当下最热门的话题,风头甚至超过智能手机及可穿戴设备.智能家居的确能颠覆现在的生活方式,但在这股热潮的背后,却衍生出一系列问题-- 智能让未来更美好 一天忙碌的工作之后,家的温馨吸引着每一个人.刚到家门口,带有摄像头的防盗门就已经自动识别出主人身份并打开.进入家中,灯光已经根据我们的习惯和周围的环境调整至最佳亮度和颜色.空调自不用说,已经将温度.适度.空气洁净度等调至最适宜人体的状态,而

微服务是什么?

解析微服务架构系列文章将分几篇描述微服务的定义.特点.应用场景.企业集成架构的演进以及微服务转型思路和技术决策考虑等内容,并以IBM技术为例介绍如何实现微服务架构转型. 为什么需要微服务架构 "微服务"架构是近期软件应用领域非常热门的概念.让我们先来看看传统IT架构面临的一些问题: 使用传统的整体式架构(Monolithic Architecture)应用开发系统,如CRM.ERP等大型应用,随着新需求的不断增加,企业更新和修复大型整体式应用变得越来越困难: 随着移动互联网的发展,企业

传统企业IT为什么对微服务叶公好龙的心态?(转)

这两年来,“微服务”.“云计算”.“大数据”.“人工智能”的概念在IT界成了新的宠儿:珠联壁合.声名远播.势如破竹.如日中天!从实践落地的情况来看:微服务诞生于互联网,当然是首先在互联网界遍地开花,高奏凯歌,所向披靡,到处布道.当传统企业刚遇到“微服务”,哇!这玩意真好啊,真是葵花宝典啊!业务隔离.独立部署.独立上线,高性能.高可用.弹性伸缩!我们公司要是也能实现这个该有多好啊!持续集成.持续部署,这不是我们整天喊整天吹的业务敏捷正需要的东东吗?然而在研究一翻之后,“洗洗睡吧!“ 抱着质疑的态度

以实例说明微服务拆分(以SpringCloud+Gradle)

前言 之前,我都是说了很多的关于微服务的概念,说到底,很多人看了之后会认为没有什么意思,因为没有实际的东西说明,即使每个概念都明白了,也很难赋之实践.所以这次,我来用一个实际的例子去说明,在实际的项目过程中我们会如何去构建我们的微服务. PS:我们只是利用场景去模拟我们微服务构建或者说拆分的整个过程,对于场景本身在实际中会出现的问题我们不做考虑,说白了就是我们不考虑场景本身在实际生活中是不是这样的. 使用SpringCloud+Gradle构建 本文目的:让你体会到服务拆分本身,引起你对服务拆分