内容简介：不知道大家是否还记得我去年的一篇文章《Web日志安全分析浅谈》，当时在文中提到了关于日志里的“安全分析”从人工分析到开始尝试自动化，从探索到实践，从思路到工程化，从开源组件到自研发，从..，其中夹杂着大量的汗水与踩过的大量的坑，文章中所提的思路以及成果也算不上有多少的技术含量，其目的一是为了总结、沉淀与分享，如果能帮助到任何为“日志分析”而迷茫不知从何着手的人便算获得了些许慰藉，其目的二是为了抛砖引玉，大家集思广益将不同的分析方法、前沿技术及优秀思路。后来在社区看到xman21同学进行实践并进行分享《We
一、前言
不知道大家是否还记得我去年的一篇文章《Web日志安全分析浅谈》，当时在文中提到了关于日志里的“安全分析”从人工分析到开始尝试自动化，从探索到实践，从思路到工程化，从开源组件到自研发，从..，其中夹杂着大量的汗水与踩过的大量的坑，文章中所提的思路以及成果也算不上有多少的技术含量，其目的一是为了总结、沉淀与分享，如果能帮助到任何为“日志分析”而迷茫不知从何着手的人便算获得了些许慰藉，其目的二是为了抛砖引玉，大家集思广益将不同的分析方法、前沿技术及优秀思路。后来在社区看到xman21同学进行实践并进行分享《Web日志安全分析系统实践》，作者试着使用了如SVM、Logistic回归、朴素贝叶斯等算法进行训练与识别，可以看出xman21同学的工程化能力，以及对大数据的理解与应用能力还是不错的。不过今天要讨论的重点并不在此，我更关心的部分是数据到底该如何驱动安全，分析方法与思路又有哪些，机器学习，数据挖掘又是如何与数据分析产生火花的，同样今天也是抛砖引玉。
二、我对数据驱动安全的定义
我在上篇文章中提到一句话“日志分析本质为数据分析，而数据驱动安全必定是未来的趋势”，那到底什么是数据驱动安全呢？也许大家都有各自不同的想法，有人说“数据驱动安全”是与外部或者内部的威胁情报进行关联，以“情报”这类数据去分析、发现、挖掘安全问题；也有人说是对现有或历史数据进行分析，判断潜在的威胁和风险；还有人说是运用大数据进行多维度进行关联分析并以此发现安全问题。以上说法其实都对，广义的来讲通过任何来源的数据运用任何分析的方法与思路发现本身的安全问题都可称之为“数据驱动安全”。而狭义来讲则是通过IT数据结合安全经验进行分析相关风险，又或者说它是一款产品，一个分析思路或方法，一组威胁情报，目前在行业中的体现便是近两年火热的SIME\UEBA\SOC\威胁情报等，但是在我看来目前行业中的安全产品是无法完全的诠释我对数据驱动安全定义。
三、行业现状
在安全行业，安全信息和事件管理（SIEM）便是对”数据驱动安全“的一个不完全的诠释，根据2016年的市场调研公开结果表明，SIEM全球销量达到了21.7亿美元且对比所有细分领域，SIME呈高增速状态，我们先来看看Gartner魔力象限中关于SIME的厂商排行（暂时没找到2018的），一眼看过去，Splunk、IBM、McAfee以及专注SIEM的LogRhythm等身处为引领者的位置。而国内的厂商似乎只有"Venustech"一家也就是启明进入象限且仅位列在"Niche Players"行列，而“Niche Players”的翻译为“投机者”、“利基者”、“特定领域者”，详细描述可以参考官方解答：
A small but profitable segment of a market suitable for focused attention by a marketer. Market niches do not exist by themselves, but are created by identifying needs or wants that are not being addressed by competitors, and by offering products that satisfy them.
我在去年的年初进行相关调研时，当时一款叫“安全易”的产品进入我的眼帘，其实此款产品并无太多新意，而当时觉得瀚思科技的主要方向应该为“业务安全”，这也是安全牛全景图在酷厂商中对瀚思科技的描述，之后并无对其太过关注，如今回过头来看，瀚思已经打破了启明在官网中提到的“作为国内唯一一家进入Gartner SIEM魔力象限的信息安全产品提供商”，说到这既遗憾又感到一点慰藉，遗憾于自己深耕于此领域，但是所得结果却尚不如人意，产品能力一直停滞不前，感觉到一些无力感，似乎遇到一些瓶颈，加上尚不明确的方向与各方面的资源缺失，慢慢似乎已经落后于人。而慰藉的是，在花花绿绿的可视化效果背后，在含有泡沫与水分的安全产品市场宣传中，有那么一小撮企业的确在做有价值的事情，在提高着行业整体的安全进化能力。
关于Gartner魔力象限有朋友说有钱就能进大约70万左右，但我对此说法不置可否。这里引用一段启明产品总监叶蓬的一段话：
中国厂商第一次入榜。对于中国客户和从业者而言，这是一个亮点。作为SIEM产品的负责人，本人有幸全程参与了这个过程。从旁观者到亲历者，体验是大大的不同，经验也是一大把，有机会另文撰述。这里只想提一句：入围Gartner SIEM魔力象限是一项十分艰苦的工作，不仅要跨越语言的障碍，还要扭转国外同行对中国厂商只能做安全硬件设备的误解。同时，SIEM产品的魔力象限考核指标是Gartner所有安全产品评估中最难、最复杂的，评价的指标项超过200个（指标之间相互关联，十分缜密）。期间，我们和分析师反复沟通，进行了十几次电话会议，数次北京的见面沟通，在美国的现场沟通，产品演示，提交各种产品资料和原理设计文档，等等等等。分析师对产品的分析十分严谨，所有能写进报告的项目都必须提供能让他信服的proven（证据）。至于技术方面，我们的SIEM覆盖了Gartner考察的大部分指标，包括流分析，ML。有机会，各位可以阅读另一个报告——《Gartner Critical Capabilities for SIEM, 2017》——一探究竟。
（图为Gartner SIEM分类下所有厂商）
关于SIEM的描述性定义：
SIEM为来自企业和组织中所有IT资源（包括网络、系统和应用）产生的安全信息（包括日志、告警等）进行统一的实时监控、历史分析，对来自外部的入侵和内部的违规、误操作行为进行监控、审计分析、调查取证、出具各种报表报告，实现IT资源合规性管理的目标，同时提升企业和组织的安全运营、威胁管理和应急响应能力。
（图为OSSIM产品）
四、数据种类
机器数据中包含客户、用户、交易、应用程序、服务器、网络和手机设备所有活动和行为的明确记录。不仅仅包含日志。还包括配置、API 中的数据、消息队列、更改事件、诊断命令输出、工业系统呼叫详细信息记录和传感器数据等。
“数据驱动安全”，首先我们需要弄清楚我们都有哪些可被分析的数据，以及数据中包含的信息，源数据中所包含的信息量越大，我们能分析出的结果就越丰富、越精准，能完成的需求与覆盖的场景就越多,而数据并非越多越好，借用某人的一句话来说就是：“数据量要恰到好处，要多到足够支撑数据分析与取证，要少到筛选掉噪音数据”。开始我对这句话懵懵懂懂，不能太多也不能太少这不是为难人嘛，在经过一系列的实际工程化实践后，我开始对此有了新的认识，这里重新定义一下这句话：“数据的数量与维度要多到能足够到支撑起得到满意的分析结果，而数据过于冗余则需要进行合理的清洗噪音数据来保证数据恰到好处”。
根据以往经验，暂时将可分析数据分为以下几类，分别为系统、应用、存储、网络设备、业务、Agent监控（严格来说其实Agent监控应该分为系统层的数据，考虑到多为需要主动或Hook才能获取所以单独分为一类）
当我们整理清楚我们的分析目标以后，首先需要的其实还不是盲目去搭建类似ELK\Hadoop的大数据分析平台，站在防御方的角度来讲，我们需要做的是问自己“这些数据对我有什么价值？”，“我的哪些安全问题可以通过分析哪些数据得到解决或缓解”，“哪里有我所需要的数据？”，“我的安全需求是什么？”，“我目前想要解决哪些和安全相关的问题？”，当我们具备一定的分析意识的时候，我们需要哪些数据自然一目了然。
五、安全需求&实践
当我们带着一定的分析意识，以及对分析数据目标的基本认识以后，我们就需要开始详细的思考，我们真正的安全需求是什么。有人说是对安全的详细的报表，有人说是发现攻击并阻断，也有人说是部署大量的安全软件与设备，加大投入聘请安全人员的预算。根据行业的专业见解来讲的，安全的需求并非是不出事，而是提升安全能力将MTTD\MTTR持续降低，即Mean Time To Detect与Mean Time To Respond，具体级别参考如下：
* 级别 0：盲视——MTTD以月计，MTTR以周或月计。有基本的防火墙和反病毒软件，但没人真正关注威胁指标，也没有正规的事件响应流程。如果这家公司掌握着国家或网络罪犯感兴趣的知识产权，那它很可能早已被盗。 * 级别 1：最小合规——MTTD以周或月计，MTTR以周计。公司做了必须做的事情以符合法规要求。高风险的区域可能接受了更细致的安全审查，但公司基本上还是对内部和外部的威胁视而不见。敏感知识产权有可能被盗。 * 级别 2：安全合规——MTTD和MTTR都以小时或天计。公司部署了足够的安全情报措施，不仅仅是“划勾式”合规，而是有着改进的安全保障。对一些威胁有承受能力，但还是对高级威胁毫无办法。 * 级别 3：警醒——MTTD和MTTR以小时计。公司有强大的检测和响应威胁的能力。它可以通过全方位监控的仪表板主动搜寻风险。能承受大部分威胁，甚至那些借助高级持续性威胁功能的类型。 * 级别 4：承受力强——MTTD和MTTR以分钟计。公司有着全面的安全情报能力和24小时不间断的安全运营中心（SOC）。尽管是高价值目标，仍能禁得起最极端类型对手的冲击。
现在我们知道了安全的终极目标，那么我们需要进行哪些分析才能达到目的呢？部分分析需求如下图：
图为当年使用ELK时头脑风暴出的安全需求，仅为分析需求中的冰山一角，我们需要根据实际情况进行合理的安全需求定制。
回顾一下Web应用日志分析的需求：
上图的需求最后基本上我们都全部具体实现了，并且抛弃了原有的ELK体系
分析的日志为我博客15年建站以来的30万日志，仪表盘为自己随意拖拽形成，走到这一步，我们替换掉了采集端、替换掉了可视化、对ElasticSearch进行定制化与调优，遇到过大大小小无数个坑，也只是跟随上了开源分析架构的步伐，让操作与分析变得更为简单，而且就如我所说，各种统计与报表并不是安全数据分析的全部，一切不贴合实际需求，不解决实际问题，不具备实际效果的产品在我眼里都是毫无价值的。我们在Web应用层已经深耕两年有余，期间我们开始尝试一些创新的思路做一些事情，不过尝试新事物就势必要付出代价。这个新事物便是我在上篇文章中提到，我觉得具有价值的部分：攻击行为溯源，然而想要真正的将它进行工程化，个人觉得是一个非常复杂的事情，即使是近两年火热的安全运营中心（SOC），都主打的是“三分技术，七分管理”的概念，而我却在最开始的想法却是实现完全的自动化溯源取证，且是针对行为的，而且还妄想只通过Web日志就做到这一点，然后便在错误的道路上越走越远，不过即使如此，我们也产出了一定的成果，且我们积累了大量的分析方法，其中包括数据预处理、数据编码、数据计算等与数据挖掘以及机器学习相关的技术储备.
到此基本上我们已经具备了两种能力，一种是宏观的安全分析，一种则是微观的事件挖掘，而基于这两种能力，我们可以有条件与技术储备去完成或覆盖更多的安全需求与用户场景。
六、数据治理
到这我们对数据种类以及分析需求有了一个初步的理解，那我接下来我需要对数据治理有一定的了解。
数据治理其实是一个广义的意思，其中包括元数据、数据聚合、数据质量、数据确权、生命周期管理等等概念，此文的数据治理为狭义，仅代表对IT数据的采集、定义、解析、增量等。
1、采集
首先我们面临的第一个问题便是，数据如何进行采集，可能使用过ELK的便知道Logstash在其中便是采集的角色，其中Logstash对日志文件进行监控，当文件有变更时，便对文件中的内容进行采集再将数据输出到指定的位置。其实类似Logstash的采集端非常之多，如下图所示，有FileBeats、Logagent、Flume、Fluentd、syslog-ng、Rsyslog等，它们都有各自的亮点。
其实作为一个功能完整的Agent来说，所具备的功能不仅仅只是监控文件然后采集和输出，作为一个完整的Agent，应该具备以下功能：（这也是我们抛弃Logstash的原因，太重量级）
1、支持丰富数据源
1.1文件
Access Log
Windows Event Log
Linux Log
1.2.存储
MongoDB
MySQL
MicroSoft SQL Server
Kafka
Redis
PostgreSQL
1.3.网络
Socket
HTTP
SNMP
2、监控信息采集模块
2.1.系统
2.2.网络
2.3.进程
2.4.内核
2.5.磁盘
这里引用七牛云logkit中的监控项：
System Metric:监控 load1、load5、load15、用户数、cpu核数以及系统启动时间等。
Processes Metric: 监控处于各种状态的进程数量, 比如运行中/暂停/可中断/空闲的进程数量等。
Netstat Metric: 监控处于各种状态的网络连接数, 比如Syn send/Syn Recv 等状态的网络连接数。
Net Metric: 监控网络设备的状态，比如收发包的数量、收发包的字节数等。
Mem Metric: 监控内存的实时状态。
Swap Metric: 监控 swap 分区的状态，比如换入换出、使用率、空闲大小等。
Cpu Metric: 监控 cpu 的实时状态，包括用量，中断时间占比等。
Kernel Metric: 监控内核中断次数、上下文切换次数、fork 的进程数等。
Disk Metric: 监控磁盘的使用情况, 包括磁盘用量、inode使用情况等。
Diskio Metric: 监控磁盘读写状态, 包括读写次数、总用时等。
Http Metric: 监控某个或者某些http请求。
Procstat Metric: 监控某个或者某些进程的信息，包括cpu,内存,磁盘io,资源限制等。
Ipmi Metric:监控各类支持ipmi接口的硬件指标。
Prometheus 节点监控: 适配各类Prometheus的node exporter
VMware Vsphere: 用于监控vsphere内虚拟机和宿主机的各项指标。
memcached: 用于监控 memcached 实例统计信息，包括运行时间、请求量、连接数等。
Elasticsearch: 用于监控elasticsearch集群的文件索引，操作系统，Java虚拟机，文件系统等信息。
安全信息采集: 用于监控机器本身的一些信息，比如网络信息，端口信息，进程信息，登录信息，暴力破解信息。
3、 数据处理模块
1.解析
2.增量
3.转换
..
4、 数据输出模块
1.Kafka
2.Mysql
3.ElasticSearch
4.MongoDB
5.Redis
...
2、定义&解析
当我们已经掌握了采集的方法后，我们接下来要做的便是定义（理解）数据和解析数据：
如我们以Web日志举例：
2017-01-01 00:08:40 10.2.1.1 GET /UploadFiles/<script>alert(1)</script> - 80 - 9.9.9.9 Mozilla/5.0+(Windows+NT+6.3;+WOW64;+rv:46.0)+Gecko/20100101+Firefox/46.0 - 200 0 0 453
根据上篇文章所提，即使我们对Web日志不怎么熟悉，也可以在配置文件中找到关于日志格式相关的配置。
那说回到定义，这里可以简单理解为对数据的理解，如果你能看一眼日志，便知道日志中包含请求时间、请求方法、请求地址、端口、请求IP、客户端信息、请求来源、响应状态、响应大小等，那么可以算初步理解了日志，如果你还知道每个字段的具体含义，知道不同的字段里面包含的信息量，如UA里面可以看到访客的系统版本、浏览器版本，访客是手机还是电脑，是 Linux 还是Mac，是IPhone还是Android，如通过URL可以推测网站到底使用了何种技术，是 PHP 还是.NET,是 Java 还是ASP。当然对Web熟悉的人可能觉得，原来这就是理解数据，好像是小意思，但是根据据我多年采坑以来发现，如果对数据理解不到位，将会严重影响分析需求的调研，甚至导致会感觉数据收回来百无一用。另外就是，并不是所有的日志都像Web日志这样容易理解与解析，我们可以来看看其他的日志数据，如Linux中的部分日志:
[ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Initializing cgroup subsys cpuacct [ 0.000000] Linux version 3.11.0-13-generic (buildd@aatxe) (gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu8) ) #20-Ubuntu SMP Wed Oct 23 17:26:33 UTC 2013 (Ubuntu 3.11.0-13.20-generic 3.11.6) [ 0.000000] KERNEL supported cpus: [ 0.000000] Intel GenuineIntel [ 0.000000] AMD AuthenticAMD [ 0.000000] NSC Geode by NSC [ 0.000000] Cyrix CyrixInstead [ 0.000000] Centaur CentaurHauls [ 0.000000] Transmeta GenuineTMx86 [ 0.000000] Transmeta TransmetaCPU [ 0.000000] UMC UMC UMC UMC [ 0.000000] e820: BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable [ 0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000007dc08bff] usable [ 0.000000] BIOS-e820: [mem 0x000000007dc08c00-0x000000007dc5cbff] ACPI NVS [ 0.000000] BIOS-e820: [mem 0x000000007dc5cc00-0x000000007dc5ebff] ACPI data [ 0.000000] BIOS-e820: [mem 0x000000007dc5ec00-0x000000007fffffff] reserved
May 30 02:22:56 localhost rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="20254" x-info="http://www.rsyslog.com"] start May 30 02:22:56 localhost rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="20254" x-info="http://www.rsyslog.com"] exiting on signal 15. May 30 02:22:59 localhost rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="20329" x-info="http://www.rsyslog.com"] start May 30 02:26:12 localhost pptpd[554]: MGR: initial packet length 18245 outside (0 - 220) May 30 02:26:12 localhost pptpd[554]: MGR: dropped small initial connection May 30 02:31:38 localhost rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="20463" x-info="http://www.rsyslog.com"] start May 30 02:31:38 localhost rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="20463" x-info="http://www.rsyslog.com"] exiting on signal 15. May 30 02:31:38 localhost rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="20483" x-info="http://www.rsyslog.com"] start May 30 02:35:59 localhost rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="20513" x-info="http://www.rsyslog.com"] start
May 30 02:22:56 localhost sudo: root : TTY=pts/0 ; PWD=/var/log/nginx ; USER=root ; COMMAND=/sbin/rsyslogd -v May 30 02:26:12 localhost sshd[20335]: Bad protocol version identification 'GET / HTTP/1.0' from **.**.*.*** May 30 02:26:12 localhost sshd[20336]: Did not receive identification string from **.**.*.***
type=DAEMON_START msg=audit(1509001742.856:3503): auditd start, ver=2.4.5 format=raw kernel=2.6.32-042stab123.3 auid=0 pid=28676 res=success type=DAEMON_ABORT msg=audit(1509001742.857:3504): auditd error halt, auid=0 pid=28676 res=failed type=DAEMON_START msg=audit(1509001860.196:6814): auditd start, ver=2.4.5 format=raw kernel=2.6.32-042stab123.3 auid=0 pid=28690 res=success type=DAEMON_ABORT msg=audit(1509001860.196:6815): auditd error halt, auid=0 pid=28690 res=failed type=DAEMON_START msg=audit(1509001887.133:9072): auditd start, ver=2.4.5 format=raw kernel=2.6.32-042stab123.3 auid=0 pid=28696 res=success type=DAEMON_ABORT msg=audit(1509001887.133:9073): auditd error halt, auid=0 pid=28696 res=failed type=DAEMON_START msg=audit(1509001918.016:849): auditd start, ver=2.4.5 format=raw kernel=2.6.32-042stab123.3 auid=0 pid=28707 res=success type=DAEMON_ABORT msg=audit(1509001918.016:850): auditd error halt, auid=0 pid=28707 res=failed type=DAEMON_START msg=audit(1509001943.060:530): auditd start, ver=2.4.5 format=raw kernel=2.6.32-042stab123.3 auid=0 pid=28713 res=success
如果大家能一眼看出这是什么日志，那可以说对Linux算是较为熟悉了，如果还能理解其中数据所包含的信息量，那可以说至少是一个经验比较丰富的Linuxer了~
那么理解数据之后该做什么呢？我们回想一下，在Web日志中如何进行基础的统计分析。
由于日志元数据的格式限定，所以并不方便我们进行统计分析，比如我们需要简单的统计每个IP的请求数量，从而找出请求量较大的访问者，按照传统的方式我们可以使用以下命令做到这一点：
awk '{print $9}' access.log | sort | uniq -c | sort -fr
但是如果我们的需求多变，如只想提取某一段时间范围访问者，又比如只想统计状态码为200的访问者等等，当需要分析的应用数量过多且数据量过大时，那么使用传统的方式效率将非常低，所以我们需要将日志进行结构化的解析，让它变成机器可读的数据，方便我们检索与统计。熟悉Logstash的人可能知道，在编写Logstash配置文件时，对日志解析时，需要用到Grok filter plugin，官方配置示例如下：
input {
file {
path => "/var/log/http.log"
}
}
filter {
grok {
match => { "message" => "%{IP:client} %{WORD:method} %{URIPATHPARAM:request} %{NUMBER:bytes} %{NUMBER:duration}" }
}
}
我们参考了Grok的优秀思路，进行了自研发解析器，我们最开始的目的非常简单，由于Logstash的插件是 Ruby 开发，而Ruby其实我们并不熟悉（虽然插件已经开源），且协同开发有点困难，也不好维护与拓展，然后便有了如图的解析框架：（图为从解析框架中提取的一部分）
3、增量
其次便是增量解析，如以Web日志攻击解析举例：
这里大家思考一个问题，这个增量解析器是如何从无到有产生的。答案是：“ 增量解析与分析需求强相关 ”
我们来举例说明：
1.你需要统计访问者的地区分布，你想知道你的网站大部分用户是来自北京还是上海，是国内还是国外
2.你需要统计访问的客户端类型，你想知道访问你的网站大部分用户是使用了手机还是电脑或平板
3.你需要统计网站日志中的攻击请求数量与正常访问的分布情况
4.你需要统计网站的访问者有哪些人曾发起过攻击，当前网络中有多少正在活动的黑客
...
这些分析需求非常常见，然而从Web日志中却无法直接做到这一点，所以此时我们需要进行增量解析。
我们可以简单的把增量解析理解为，在原数据的基础上增加更丰富的数据来满足多样的分析需求。
如： IP >> 地区
Ua >> 客户端信息
Url >> 是否具有攻击特征
...
ELK体系中，Logstash的 Filter Plugins 便是对此的不完全诠释
4、计算
可能大家对计算这个需求会有点疑惑，不知道计算的需求到底在哪，说实话最开始我们有这种需求时，其实只是单纯的因为ElasticSearch已经无法满足我们的多层聚合搜索需求，所以我们在数据处理过程中进行计算，通过计算结果进行二次分析。后来，结果我们一些相关的研究，我们尝试将数据挖掘、机器学习与日志分析进行结合，对日志中的计算结果进行各类算法的研究与尝试，希望能使用非传统的方式达到我们的分析需求，总得来说，我们计算有两种很直接的需求： 1.完成在ElasticSearch中无法实现的复杂的聚合统计需求 2.将计算结果进行数据挖掘、机器学习等场景
当然这里说的是我们在实践过程中所遇到的需要计算的场景，并非指的是计算的全部作用，为了达成某个需求而使用需要使用计算的场景都可算为此范畴。
举个栗子：
使用LOF（Local Outlier Factor）异常检测算法检测异常访问者
以上只是两次浅层次的尝试，虽然还无法替代传统的方式进行安全分析，但至少我们通过非传统、无规则的方式找到的异常的IP与异常的请求，虽然准确率与召回率还有待进一步实践确认，但至少我们的思路已经打开了。
另外不知道大家是否记得在上篇文章中在没有使用ELK这样的技术体系之前，我们是对数据进行统计分析的，如果有印象的朋友可能就知道，是采用了类似计算的方式，将日志解析到 Mysql 以后，采用规则过一遍日志，然后将命中结果存入到Mysql现成”统计结果表“，最后采用 SQL 语句进行分组查询统计，然后利用Excel进行可视化。这个”统计结果表“所说的结果，便是我们这的计算结果，我们根据分析需求，从不同的维度，对数据进行计算，这个维度可以是针对一个IP、一个路径、甚至某一个Referer或Ua,如图为针对IP进行不同维度指标的统计计算结果：
整个计算过程是在日志的处理过程中实现的，根据需求，计算顺序可以进行自定义，不过通常都是在解析及增量解析完成后进行，因为增量解析完以后，信息更丰富，能进行计算的维度更丰富。
七、数据分析方法
1、经验转化
所谓的经验转化，便是将专家对数据的理解以及分析经验、分析逻辑等进行转化，形成可工程化应用的一个过程。基于攻击特征的规则统计便是对此一个最浅显的一个应用案例。首先我们来简单讲讲什么是专家经验，我还是以上篇中撰造的日志为例： eg:
00:01 GET http://localhost/index.php 9.9.9.9 200 [正常请求]
00:02 GET http://localhost/index.php?id=1 ' 9.9.9.9 500 [疑似攻击]
00:05 GET http://localhost/index.php?id=1 ' and 1=user() or ''=' 9.9.9.9 500 [确认攻击]
00:07 GET http://localhost/index.php?id=1 ' and 1=(select top 1 name from userinfo) or ''=' 9.9.9.9 500 [确认攻击]
00:09 GET http://localhost/index.php?id=1 ' and 1=(select top 1 pass from userinfo) or ''=' 9.9.9.9 500 [确认攻击]
00:10 GET http://localhost/admin/ 9.9.9.9 404 [疑似攻击]
00:12 GET http://localhost/login.php 9.9.9.9 404 [疑似攻击]
00:13 GET http://localhost/admin.php 9.9.9.9 404 [疑似攻击]
00:14 GET http://localhost/manager/ 9.9.9.9 404 [疑似攻击]
00:15 GET http://localhost/admin_login.php 9.9.9.9 404 [疑似攻击]
00:15 GET http://localhost/guanli/ 9.9.9.9 200 [疑似攻击]
00:18 POST http://localhost/guanli/ 9.9.9.9 200 [疑似攻击]
00:20 GET http://localhost/main.php 9.9.9.9 200 [疑似攻击]
00:20 POST http://localhost/upload.php 9.9.9.9 200 [疑似攻击]
00:23 POST http://localhost/webshell.php 9.9.9.9 200 [确认攻击]
00:25 POST http://localhost/webshell.php 9.9.9.9 200 [确认攻击]
00:26 POST http://localhost/webshell.php 9.9.9.9 200 [确认攻击]
具有安全经验的人应该不难看出，我们的经验主要可总结为以下：
1.Web攻击特征
可通过请求判断是否属于攻击请求且可判断出所属何种攻击以及攻击可造成的危害或者成功后达到的目的
2.攻击手法
从攻击行为上进行逻辑分析，判断是否构成某种行为链
那么我们如何对此经验进行转化呢？我们先来说说Web攻击特征，可以看到通过这个经验，我们能具体得到以下信息：
请求属性：确认攻击、疑似攻击、正常请求
技术攻击类型：SQL注入、文件下载、敏感、XSS跨站、命令执行、XXE..
攻击行为类型：利用SQL注入获取用户信息、利用命令执行写入webshell、利用文件下载漏洞下载配置文件..
判定原因：命中XX正则、满足XX条件、符合XX逻辑
风险等级：根据攻击行为类型、技术攻击类型等结果进行综合风险评定
..
为什么我们看到Web请求的时候能得到这么丰富的信息呢，原因是因为我们丰富的安全攻防经验，我们对Web应用的深度理解，我们对开发语言的理解，对HTTP的理解，对容器的理解，对业务逻辑的理解，然而想要把这些经验完全的工程化是非常复杂的事情，想要完全做到几乎不可能，而业内传统的做法是，使用简单的规则匹配进行转化，我们在数据治理的数据增量解析过程中加入我们的”安全经验“,在日志流处理过程中，首先进行格式解析，随后便调用安全专家编写的攻击规则进行增量解析。对此的实践工程参见： https://github.com/anbai-inc/AttackFilter/
那么攻击手法又该如何进行经验转化呢？我们都知道，攻击手法是一个逻辑上的东西，不像文本类的攻击特征只需要进行关键字、正则匹配即可，而攻击手法属于行为类攻击特征，简单说就是文本类通过正则进行匹配，匹配成功则认为是XXX攻击，而行为类的特征是具有逻辑性的，比如上面的例子，我们看到了大量的后台地址404了，会联想到这是一次后台爆破行为，后台地址是文本类经验，而 大量后台地址404 则属于行为类经验，又比如我们看到攻击者注入用户信息后开始了扫描后台，那么很有可能攻击者已经得到了管理员账户密码，但是还没有找到登录入口，这种具有逻辑性的行为，那么这样的逻辑性经验我们又该如何转换呢？开始尝试的做法是：设计简单的攻击行为链的模型，通过攻击类型、攻击行为等信息进行规则化关联。
渗透步骤：
攻击分类：
攻击行为分类：
攻击行为链
引用一张图来描述这个过程：(此图来源于碳基体)
通过对行为发生的逻辑顺序进行搜寻，我们找到了所有在日志中出现的符合行为逻辑的的行为链
首先通过对渗透步骤、攻击类型、攻击行为类型等进行定义，并将攻击逻辑直接简化为攻击行为步骤，实际上mode1中的[1,2,5,6,10]对应便是攻击行为分类中的各个行为，组成起来便是”探测注入“、”利用SQL注入获取数据“、”后台扫描“、”上传文件“、”恶意webshell小马“，但是实际工程化的时候并非这么简单，会遇到诸多的问题，首先面临的便是日志分析七大难题，规则不够精细化，误报漏报问题，其次就是可信度问题，还有就是需要判定攻击成功的可能性问题，这种具有逻辑性的经验转化是我当初想要实现的Web自动化溯源流程中最为关键的环节.
虽然实现后问题诸多，但从提出想法，到目前实现，也算是迈出了一大步。而后续，这种转化还会持续下去。
对于经验转化，这些只是冰山一角，将领域知识应用到实际的工程化中，其实在目前的大部分安全产品中随处可见。
2、统计分析
其实”统计分析“和数据分析一样也具有一个广义的含义，学术中的统计分析包含了调查、收集、分析、预测等，涉及课程包括数学分析、解析几何、高等代数、微分方程、复变函数、实变函数与泛函分析、近世代数。这里仅指传统的统计分析，如有统计学大佬、高等数据大佬、概率论大佬或者学SPSS\SAS的大佬请轻喷。 先说说如何来理解传统的统计分析吧，我们先来看看统计局的一个[报表](http://www.stats.gov.cn/tjsj/tjgb/rdpcgb/qgkjjftrtjgb/201810/t20181012_1627451.html)：
可以看到并非不复杂，一眼看去基本是普通公众可以理解的统计数据。嗯，这就是我们要说的统计分析。
在日志中，我们也需要统计分析，虽然微观的分析，具体的事件线索，从日志中发现0day，从流量中捕获异常行为这些来得更直接，但是宏观上的安全分析一样具有实际意义，虽然我们技术人员对各种花哨的大屏嗤之以鼻，但是如果没有宏观的安全状态，又如何开始深入，先广后细方能掌握全局。我们可以根据不同的场景进行思考，哪些指标是值得我们统计的，哪些统计分析是具有较大的价值与实际意义的，是否可以通过专家经验完成额外的统计分析需求。一旦理解清楚这些，我们想要开始进行统计分析便是一件非常简单的事情，下面的统计图便是我对一个仅具备初级研发能力不了解系统日志的小组成员进行培训后所完成的对Windows系统日志进行统计后的结果：
要进行统计分析这一步骤，最关键的步骤在于对统计分析需求的调研，而数据定义、数据解析、增量解析、聚合搜索、可视化等都是建立在此步骤，如对此过程有兴趣者，找机会另起一篇文章。
3、机器学习
其实这是一个并不太想讲到的主题，因为在国内安全行业中，大家都在提自己具有人工智能（可能也包括我们自己），但实际具有效果，实现了真正的安全价值的，其实很稀有，行业现状是大家更多的是利用这个”新型“、”前沿“的技术来进行镀金与推广。 那么什么是机器学习呢？这个技术到底能做到什么？它的优缺点是什么？它又是如何和安全扯上关系的？..
翻了翻自己的笔记看到，作者本人正真开始接触机器学习是在去年的6月份，在此之前也仅仅停留在知道这个名词。机器学习的专业定义：
机器学习(Machine Learning, ML)是一门多领域交叉学科，涉及概率论、统计学、逼近论、凸分析、算法复杂度理论等多门学科。专门研究计算机怎样模拟或实现人类的学习行为，以获取新的知识或技能，重新组织已有的知识结构使之不断改善自身的性能。 它是人工智能的核心，是使计算机具有智能的根本途径，其应用遍及人工智能的各个领域，它主要使用归纳、综合而不是演绎。
其实要理解机器学习还是有点复杂的事情，我们来举个教科书上的例子：
我现在要对花瓣进行分类，人之所以能区分，大部分依赖的对某一事物的记忆。而机器学习的逻辑是，先基于数据进行学习，首先花瓣的宽度与长度代表是区分两种花瓣的特征，然后花瓣类别表示满足此特征则是某类，大家思考一下如果就有两种花瓣宽度长度都有一样，但是就是不是一种花，它们可能颜色不一样，可能有些长在树上，有些是长在地上，其实这个思考的过程，便是用人的思维进行特征提取，找出对学习出类别影响较大的因素，还有一些时候，我们也无法得知那些特征是对类别有较大的影响怎么办，这个时候就需要接触到特征选择了，特性选择的作用是衡量该特征和响应变量之间的关系的一种计算方法，有兴趣的同学可自行学习这里不再展开。
x1 + x2 - 2 = 0，最后我们得到分类函数g(x1,x2)：
x1 + x2 - 2 ≥ 0变色鸢尾：0.5 * x1 + x2 - 2 ＜ 0
此时分类问题就变成了一个数学问题，我们只需要将花瓣的宽高输入到函数便能得到花瓣的类型，但实际情况中，特征点在特征空间中的位置分布非常复杂，因为现实数据中会存在多种可能性，采用观察和尝试来得到分类函数几乎是不可能的，也是没有效率的，因此我们需要通过一些方法来自动学习并获得这个分类函数，这个便是对机器学习最简单的理解。通过输入数据进行学习，通过学习得到模型，而这个模型其实就是一个数学公式，也就是分类函数。
为了了解机器学习所涉及到的知识领域，我对一本书进行了提词，并希望以此来宏观的了解所有相关的知识点来进行有计划的学习，如图：
那么机器学习在安全中有哪些真实场景呢？根据兜哥的一系列实践过程，场景如下：
异常主机操作行为
检测恶意Webshell
检测DGA域名
检测网站CC攻击
验证码识别
检测Java溢出攻击
识别正常用户与黑客
识别XSS攻击
识别僵尸网络
发现疑似被盗账号
检测撞库行为
检测疑似刷单行为
检测敏感转账行为
检测Web攻击行为
检测内部敏感行为
兜哥在《Web安全之机器学习入门》中进行了大量实践，但是有读者却在知乎中评论到”没有对具体的算法和公式进行详解“，而我想说的是，实践缺乏了理论的支撑，导致初学者只能强行照搬，而无法灵活变通，无法将具体的思路应用到实际场景中，还有就是很多前置知识掌握不足，导致无法真正的应用机器学习实现安全相关的需求。
对于想要入门机器学习的同学来说，建议先学习打好基础底子，弄清楚机器学习的基本概念，知道什么是有监督学习、无监督学习、特征点、特征空间、向量、张量等基础知识。然后就是了解机器学习的各个算法的优缺点。
对于想要实践学习机器学习的的同学可以参考作者之前使用SVM进行XSS识别的一个小Demo，可帮助大家快速体验机器学习的魅力之处，Github地址： https://github.com/jearyorg/student
4、数据挖掘
数据挖掘最早我对它的定义是很模糊的，也并无太多热度，然而后来经过大量研究与实践后，我发现我对此的热衷程度甚至要高于机器学习，原因很简单，它无需安全经验，无需打标签，可以实现探索性的分析，实现对数据进行”未知的分析“，甚至不需要具有任何已知经验，仅需要简单的将数据放入挖掘算法进行测试，便能得到惊喜。 （PS：机器学习与数据挖掘其实相同知识领域很多，其本质区别在于目的不同，字面解释就是一个是为了学习，一个是为了挖掘） 数据挖掘的专业定义是：数据挖掘（Data Mining，简称DM），是指从大量的数据中，挖掘出未知的且有价值的信息和知识的过程 数据挖掘主要有四类任务：异常检测、聚类分析、关联分析、预测建模，具体场景如： ”对网站访客进行异常检测，找出具有异常行为的访客“ ”对访问人群进行聚类，将行为相似的访客聚为一类“ ”对系统日志、Web日志进行关联，挖掘系统与Web之间的关联模式“ ”根据历史日志中的攻击行为，预测攻击者在未来的攻击力度”
下图即为采用了聚类算法进行人群划分的效果，我们在数据挖掘的基础上进行二次分析，从而成功的将人群划分为不同的类型，进而实现了无规则挖掘攻击者。
数据挖掘在安全领域最大的作用便是，在不具备专家经验或者安全经验没有覆盖到的地方进行挖掘，帮助我们打破常规思维进行数据分析，当然它还有非常多的作用，比如，我们可以通过挖掘找到所有非正常的请求，然后通过规则找到所有具有攻击特征的请求，然后将两者进行交叉比对，无论比对结果如何，我们都有所收益，可能你能得到一些规则未覆盖的攻击，或者你能找到自己规则写得不足的问题，又或者你能直接发现0day，再或者你规则写得特别全，但是你发现有些异常请求算法没有挖掘出来，那么你可以去思考到底还有哪些特征对算法的影响比较大，然后便可以去增加或者减少某个特征的权重。
八、数据分析总结
从开始两年前开始在这个领域进行实践，作者就开始思考，想要在这个领域成长，到底需要涉及哪些领域呢？哪些技能是不可或缺的呢？于是作者在一年前画了此图：
其实说回本质，整个过程并不复杂，无非就是”拿到数据“ -> "开始分析" -> "得到结果"，但是想要分析的结果丰富、全面、精准却不是一件容易的事情，有非常多的因素会影响我们的结果。如数据量、数据维度、数据质量、领域知识、分析方法、关联逻辑等等。
我们来重新梳理一遍整个分析的逻辑：
1、安全需求调研
如果我们只是为了解决某些安全需求，那么没有必要向专业的安全产品靠齐，我们仅仅需要思考的是，我们的安全痛点在哪，比如：对外开放服务的机器太多，无法具体掌握每台机器应用受攻击的状况；目前的Waf、IDS大量告警，需要处理的警告太多了，想二次分析降低误报，帮助人工提高验证效率；对服务器的出网行为较为关注，需要对所有的出网连接进行风险分析；对大量的无差别攻击并不感冒，想进行合理的筛选并让我方安全人员只需关注目的性较强的攻击者；
当我们有了具体的需求以后，当然你可以有所有的需求，但是根据个人经验来看，需求越多需要投入的资源和时间成本就越高，所以明确的做法是将安全需求进行优先级的排序，然后逐个击破。
2、数据调研
当我们理解清楚需求，明确了我需要达到的理想效果，且已经拥有一个需求清单以后，我们接下来要做的便是去调研需要达到我们的需求到底需要哪些数据，且数据量与数据维度是否能支撑，且需要考虑是否具备可分析性，数据的可信度（通过此数据分析出的结果有几分可信度），如何理解定义数据，数据的质量如何，数据中包含哪些信息量，数据是否可以进行增量，数据与数据之间是否存在关联关系，数据是如何产生的，我们是否能很轻易的获取这个数据等等
3、数据治理
如果说前两步是对需求和数据的调研，那么到这里一步便开始需要一些实践操作了，当时根据我们的实际经验，前两步的调研质量，直接影响到我们后面是否能完成我们的分析需求。当我们弄清楚我们需要的数据在哪以后，我们需要采用相应的采集方式，可能是日志文件监控，可能是采用应用埋点，也可能是主动式的Agent采集。当我们拿到数据以后，我们需要根据需求将数据进行解析、归一化、数据增量、数据计算等等操作
4、分析方法
分析方法其实并不是狭义的特指某一个方法，分析方法是多变的，只要能达到我们的需求都可以称之为一种”方法“，如果你的数据质量不错，那么有时候一个简单的结构化查询语句便是一种分析方法，而有时候分析方法可能是”增量+结构化查询“的组合，有时候可能分析方法是”计算+结构化查询“的组合，有时候分析方法可能是”计算+数据挖掘“的组合，又或者是一次关联的查询，又或者是只是一次简单的统计分析，又或者是”计算+机器学习“的模型训练与实际应用。分析方法虽然千变万化，但是逃不出一个本质，在原有的数据上通过合理的方法得到有用的结论。
5、可视化/价值输出/结果验证
如果你已经完成了一些分析，得到了一些结果，那么到这一步便是对结果进行验证，对其中的具有通用的价值进行提取，最后便是对数据进行可视化。并根据得到的结论重新思考整个流程，思考是否达到了我们的分析目的，思考哪些步骤还有提升的空间，是否能进一步的提高数据质量，是否能使用不同的分析方法得到更好的答案。
其实整个过程并不复杂，但如果需要考虑实际的工程化问题，需要考虑拓展性、通用性、可维护性等问题的话，那么整个工程的建设将会非常复杂，因为在整体平台中，我们需要无缝拓展各类数据，需要考虑数据之间如何关联，需要考虑增量后的数据维护，还要考虑数据不同的时间维度，另外还有就是不同的算法如何兼容整个线上的数据，还要考虑算法如果有特殊的计算需求，如对数据进行归一化处理、one-hot、TF/IDF等等，我们在实践完成数据分析平台后，由于平台的技术架构限制，导致很多分析需求根本无法在原有的平台上直接应用，一些特殊的需求甚至需要改动架构才能实现，作为真正的数据分析平台，需要具备较为良好的设计思想，抽象能力，否则最后只能进退两难，最后造成资源浪费。
九、数据价值输出
在安全这个领域，最直接输出的价值便是威胁情报，当然通过数据分析得到的任何有价值或实际意义的信息或结论都可称之为数据价值的输出。
个人最开始听说“威胁情报”是在16年，那时候对这个词的认识和理解仅仅停留在“IP、域名、文件Hash、邮箱”等关联出的信息，翻了翻自己的所以关于威胁情报的笔记，发现正式开始系统性的学习、整理、收集以及尝试是在17年的6月左右，遗憾的是根据当时的阶段性规划，我们的重心并不在此，而在于通过应用本身或系统本身产生的日志数据来分析攻击者的行为从而实现溯源，所以威胁情报关于这一块作者的经验还是有限。其实溯通常情况下溯源的重要需求点在于寻找攻击者（即准确得知关于所有敌方的情报），而其次才是分析历史行为，所以如果仅把重心放在从内部历史数据分析行为这一个环节上，并不能实现真正意义的溯源。
不过万物相通，在本质上情报也属于数据的一种，如何分析，如何关联，如何验证情报的可信度，其中的方法非常的类似。
那么我们从数据中到底能提取出哪些有用的信息呢？大概分类如下：
一、黑客/团伙人物画像
二、黑客动向
三、黑客攻击手法模型库
四、妥协指标(IOC)
五、黑客 工具 指纹库
此分类并不严谨，此处是按照不同的侧重点进行区分，而非业内标准，仅仅只是告诉大家，我们可以去做这些方向的数据分析与提取。
其实安全的本质是信息是否对等，在攻击者的视角里，攻击者知道了我们不知道的系统脆弱点所以导致我们被攻陷，在防御者视角里，我们无法得知关于攻击者的信息，导致风险被搁置从而造成持续损失，而情报是对信息对等的一个很好的诠释与缓解方案。
关于情报获取有非常多的方式，而其中最主要的来源便是通过各类安全产品记录的数据进行提取与管理，如EDR、IDS、IPS、Waf、流量审计、开源情报、日志审计。某些厂商，先天具有情报的来源方式，如拥有三分天下的阿里云，又比如在流量分析行业领头的科来，又比如占领终端安全一席之地的360天擎，然而如果不具备对数据的理解能力以及关联能力，以及对此的工程化能力，那么数据中的价值将无法完全发挥。
十、安全场景杂谈
目前行业内的安全产品，其实基本都和数据分析强相关，你能在很多产品中看到各种不同分析的影子，而分析的策略基本来源于安全专家的领域知识，而某些在安全专家脑海里的“经验”却很难灵活的进行工程化，从而给大家一种感觉，所有的安全产品都是基于策略与规则，当有安全厂商说，我们是语法树解析，我们是应用时保护，我们是机器学习，我们是无监督算法智能识别等等等的说法的时候，总会有人对此不屑一顾又或者刨根问题，甚至开怼说，你这不还是规则麽，当你终于让客户理解了你区别于传统的点的时候，客户又会将传统的安全产品效果和你讲述的进行对比，如别人的WAF一天能拦截并记录到十万百万的攻击，为啥你家的RASP一个月了啥动静也没有，而用户殊不知是因为还没有人能真正的攻击成功并进入到Hook点（这是一个值得思考的产品改进上的问题），又比如用户会说，明明我家的SIEM帮我统计出这一周有100多个黑客，怎么你就分析出只有4个黑客，你家的分析能力也太弱了，殊不知别人家是 命中规则的IP 就算为一个黑客，而专业的分析却站在时间维度上、行为维度上、情报维度上、无差别攻击上进行了攻击者合并，最后剔除出真正具有攻击性意图上的黑客（这是一个值得思考并改进的的分析报告完整性的问题）。
那么关于 数据驱动安全 可用于哪些安全场景呢？如下：
应用安全风险管理(ASRM)
安全信息与事件管理(SIEM)
网络态势感知(CSA)
安全运营中心(SOC)
态势感知与安全运营平台(NGSOC)
用户行为分析(UEBA)
威胁情报(TI)
..
目前安全行业的安全产品五花八门，各有所长又各有所短，大部分安全产品仅在某一些点上做的十分优秀，而安全是一个面，未来，谁能将数据运用到极致，且领先建立起安全的生态，谁便能成为整个行业的引领者。
十一、数据分析平台工程化建设思路
说起工程化，大家似乎都马上想到ELK，但是随着安全需求的复杂化，使用ELK已经很难完成我们的需求，且其中的维护成本过高，比如你要使用学会Ruby写Logstash的插件来完成各种Filter需求，且不同的终端需要进行不同的配置。又比如你要从网络连接信息中获取数据，从进程中获取数据，甚至从内存中获取数据，而此时Logstash已经无法满足。另外就是使用ELK很难进行有计算需求的部分，而机器学习和数据挖掘所学习的便是大量结果计算后提取的特征值。另外就是在ELK体系中，很难把机器学习的流程完美的加入到其体系当中。我们先来看看关于大数据体系常规的技术架构：
”纯净版“：
”专业版“：
”简易流程图“：
如果你已经自行搭建或者使用过类似ELK、Splunk、安全易以及我们的鲲鹏数据分析平台等类似的数据分析产品，那么想要构建这样一个大数据体系其实并不复杂，各位同学可以根据自己的需求或者目的将侧重点放在不同的地方，如你想更深的理解整个体系中的每个流程，那我建议你首先实际部署整套环境。首先安装在需要采集日志的地方安装并配置Logstash、Flume、FileBeat，然后搭建Kafka并将采集端采集的数据输入到Kafka集群，然后搭建Storm或者Spark集群，并采用自己熟悉的语言进行研发（Storm和Spark都提供各种语言的开发接口，如果你只是为了学习可以使用Python/Scala，如果考虑后期维护性可以使用Java）,Spark案例： https://github.com/apache/spark/tree/master/examples/src/main 研发的主要功能为从Kafka消费数据，并根据需求完成数据的标准化、结构化、增量解析、计算等等，假设你只是想要从宏观统计安全状况，那么一个日志格式解析器+一个安全相关的增量解析器基本上就能满足你的需求，最后我们将解析后的结果缓存到 Redis 或者定时存储到ElasticSearch，然后通过Kibana或者其他可视化工具进行相应的可视化即可。如果你能完成到这一步，那么基本上你已经具备了基本的分析平台构建能力，而想要让平台的安全能力不断提升，想要实现各种不一样的安全需求，那么则需要考虑的就是平台的通用性、拓展性、维护性，协同开发。还有就是前面所提到的经验转化以及其他分析方法，如何将不同的研究成果进行工程化的转化并在此架构中测试与实践
十二、结束语
写完这篇总结的文章，作者感觉到了自身的渺小，”数据驱动安全“，其实是一个非常大的定义，在提的人很多，在做的人也很多，但想要真正的把数据运用到极致，我们还有很远的路要走。
十三、拓展阅读
数据相关
https://www.freebuf.com/articles/database/68877.html
https://www.freebuf.com/articles/others-articles/66214.html
http://www.91ri.org/14290.html
https://www.cnblogs.com/alisecurity/p/6378869.html
https://blog.csdn.net/lzc4869/article/details/79106870
https://www.jeary.org/scret.html开源奉献
https://bloodzer0.github.io/ossa/infrastructure-security/host-security/log-analysis/
PS：bloodzer0通过自身的丰富甲方经验，维护以及分享了关于企业安全体系建设相关的技术与思路，后期作者也会参与到bloodzer0的工作中，和他一起维护日志分析相关的知识与经验
题外话
作者在数据分析领域的经验其实在本人看来还尚浅，既无法和某些具有APT追踪能力的团队相媲美，又无法和某些专业深耕数据产品的团队所匹敌。作者在此领域的经验不足两年，且深耕于此的初衷仅仅是因为想解放双手，让分析从此不再需要耗费大量的人工精力，让应急从此变得轻松又有效率，让聪明且思想跳跃的安全从业者（黑客）能把精力放在更重要的事情上（改变世界），这也是分享此篇文章的原由。反观业内，作者从两年前开始学习数据分析相关的知识，发现能学习的东西非常有限，所有的知识零零散散，和安全相关更加是寥寥无几。对于初学者来说甚至连学习到ELK搭建进行统计安全概况都觉得是一件非常有技术含量的事情，而我原本认为这样的文章或知识应该属于常识，就像你去搜索如何安装JDK环境或者搜索某个状态码代表什么含义一样。说回现状，目前行业内的分析产品大部分都停留在某位大佬所说的“看热闹”阶段，分析类产品需要进一步提升自身的能力，需要进一步证明自身的能力与价值，真正体现“数据驱动安全”，而不是“热闹展现安全”。
此篇分享其实在11月初就开始撰写，大约花了三周的业余时间构成，初次投稿在11月底-12月初，由于公司领导认为其中涉及未投入到市场的产品被公开，其中包括产品界面（原型），实现流程及思路，故本人联系版主对文章进行了处理，个人把此次事件理解为“资本主义与技术分享”的一次冲突，考虑到涉及利益相关问题，本人已经将溯源相关产品图以及相关具体技术实现逻辑进行了修订与删除，所以大家无法看到目前溯源相关的成果，如果对此产品有兴趣的需求方，欢迎通过 官方&商务 渠道联系进行产品演示。
以上所述就是小编给大家介绍的《数据驱动安全方法论浅谈》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
