随着企业数据的快速增长，数据管理和分析变得越来越具有挑战性。传统的数据管理方法已经难以满足企业对实时数据处理、li>
如何利用云服务器进行大数据分析
利用云服务器进行大数据分析通常需要以下步骤：
- 选择云服务提供商：选择一家提供大数据分析服务的云服务提供商，例如 Amazon Web Services (AWS)、Microsoft Azure 或 Google Cloud Platform (GCP)。
- 创建云服务器：在所选云服务提供商上创建一组云服务器，用于存储和处理数据。
- 部署大数据平台：在云服务器上部署一个大数据平台，例如 Apache Hadoop 或 Apache Spark。
- 加载数据：将数据从各种源加载到云服务器上，例如数据库、日志文件或传感器。
- 处理和分析数据：使用大数据平台上的数据处理和分析工具，执行复杂的数据分析任务。
- 可视化结果：将分析结果可视化，以便更轻松地理解和共享见解。
如何实现支持数亿用户的长连消息系统
此文是根据周洋在【高可用架构群】中的分享内容整理而成，转发请注明出处。
周洋，360手机助手技术经理及架构师，负责360长连接消息系统，360手机助手架构的开发与维护。
不知道咱们群名什么时候改为“Python高可用架构群”了，所以不得不说，很荣幸能在接下来的一个小时里在Python群里讨论golang….360消息系统介绍360消息系统更确切的说是长连接push系统，目前服务于360内部多个产品，开发平台数千款app，也支持部分聊天业务场景，单通道多app复用，支持上行数据，提供接入方不同粒度的上行数据和用户状态回调服务。
目前整个系统按不同业务分成9个功能完整的集群，部署在多个idc上（每个集群覆盖不同的idc），实时在线数亿量级。
通常情况下，pc，手机，甚至是智能硬件上的360产品的push消息，基本上是从我们系统发出的。
关于push系统对比与性能指标的讨论很多同行比较关心go语言在实现push系统上的性能问题，单机性能究竟如何，能否和其他语言实现的类似系统做对比么？甚至问如果是创业,第三方云推送平台，推荐哪个?其实各大厂都有类似的push系统，市场上也有类似功能的云服务。
包括我们公司早期也有erlang，nodejs实现的类似系统，也一度被公司要求做类似的对比测试。
我感觉在讨论对比数据的时候，很难保证大家环境和需求的统一，我只能说下我这里的体会，数据是有的，但这个数据前面估计会有很多定语~第一个重要指标：单机的连接数指标做过长连接的同行，应该有体会，如果在稳定连接情况下，连接数这个指标，在没有网络吞吐情况下对比，其实意义往往不大，维持连接消耗cpu资源很小，每条连接tcp协议栈会占约4k的内存开销，系统参数调整后，我们单机测试数据，最高也是可以达到单实例300w长连接。
但做更高的测试，我个人感觉意义不大。
因为实际网络环境下，单实例300w长连接，从理论上算压力就很大：实际弱网络环境下，移动客户端的断线率很高，假设每秒有1000分之一的用户断线重连。
300w长连接，每秒新建连接达到3w，这同时连入的3w用户，要进行注册，加载离线存储等对内rpc调用，另外300w长连接的用户心跳需要维持,假设心跳300s一次，心跳包每秒需要1w tps。
单播和多播数据的转发，广播数据的转发，本身也要响应内部的rpc调用，300w长连接情况下，gc带来的压力，内部接口的响应延迟能否稳定保障。
这些集中在一个实例中，可用性是一个挑战。
所以线上单实例不会hold很高的长连接,实际情况也要根据接入客户端网络状况来决定。
第二个重要指标:消息系统的内存使用量指标这一点上，使用go语言情况下，由于协程的原因，会有一部分额外开销。
但是要做两个推送系统的对比，也有些需要确定问题。
比如系统从设计上是否需要全双工（即读写是否需要同时进行）如果半双工，理论上对一个用户的连接只需要使用一个协程即可（这种情况下，对用户的断线检测可能会有延时），如果是全双工，那读/写各一个协程。
两种场景内存开销是有区别的。
另外测试数据的大小往往决定我们对连接上设置的读写buffer是多大，是全局复用的，还是每个连接上独享的，还是动态申请的。
另外是否全双工也决定buffer怎么开。
不同的策略，可能在不同情况的测试中表现不一样。
第三个重要指标：每秒消息下发量这一点上，也要看我们对消息到达的QoS级别(回复ack策略区别），另外看架构策略，每种策略有其更适用的场景，是纯粹推？还是推拉结合？甚至是否开启了消息日志？日志库的实现机制、以及缓冲开多大？flush策略……这些都影响整个系统的吞吐量。
另外为了HA，增加了内部通信成本，为了避免一些小概率事件，提供闪断补偿策略，这些都要考虑进去。
如果所有的都去掉，那就是比较基础库的性能了。
所以我只能给出大概数据，24核，64G的服务器上，在QoS为message at least，纯粹推，消息体256B~1kB情况下，单个实例100w实际用户（200w+）协程，峰值可以达到2~5w的QPS…内存可以稳定在25G左右，gc时间在200~800ms左右（还有优化空间）。
我们正常线上单实例用户控制在80w以内，单机最多两个实例。
事实上，整个系统在推送的需求上，对高峰的输出不是提速，往往是进行限速，以防push系统瞬时的高吞吐量，转化成对接入方业务服务器的ddos攻击所以对于性能上，我感觉大家可以放心使用，至少在我们这个量级上，经受过考验，go1.5到来后，确实有之前投资又增值了的感觉。
消息系统架构介绍下面是对消息系统的大概介绍，之前一些同学可能在gopher china上可以看到分享，这里简单讲解下架构和各个组件功能，额外补充一些当时遗漏的信息：架构图如下，所有的service都 written by golang.几个大概重要组件介绍如下：dispatcher service根据客户端请求信息，将应网络和区域的长连接服务器的，一组IP传送给客户端。
客户端根据返回的IP，建立长连接，连接Room Service，长连接网关，hold用户连接，并将用户注册进register service，本身也做一些接入安全策略、白名单、IP限制等。
register service是我们全局session存储组件，存储和索引用户的相关信息，以供获取和查询。
coordinator service用来转发用户的上行数据，包括接入方订阅的用户状态信息的回调，另外做需要协调各个组件的异步操作，比如kick用户操作,需要从register拿出其他用户做异步操作 service是存储访问层，承担了对redis和mysql的操作，另外也提供部分业务逻辑相关的内存缓存，比如广播信息的加载可以在saver中进行缓存。
另外一些策略，比如客户端sdk由于被恶意或者意外修改，每次加载了消息，不回复ack，那服务端就不会删除消息，消息就会被反复加载，形成死循环，可以通过在saver中做策略和判断。
（客户端总是不可信的）。
center service提供给接入方的内部api服务器，比如单播或者广播接口，状态查询接口等一系列api,包括运维和管理的api。
举两个常见例子，了解工作机制：比如发一条单播给一个用户，center先请求Register获取这个用户之前注册的连接通道标识、room实例地址，通过room service下发给长连接 Center Service比较重的工作如全网广播，需要把所有的任务分解成一系列的子任务，分发给所有center，然后在所有的子任务里，分别获取在线和离线的所有用户，再批量推到Room Service。
通常整个集群在那一瞬间压力很大。
deployd/agent service用于部署管理各个进程，收集各组件的状态和信息,zookeeper和keeper用于整个系统的配置文件管理和简单调度关于推送的服务端架构常见的推送模型有长轮训拉取，服务端直接推送（360消息系统目前主要是这种），推拉结合（推送只发通知，推送后根据通知去拉取消息）.拉取的方式不说了，现在并不常用了，早期很多是nginx+lua+redis，长轮训，主要问题是开销比较大，时效性也不好，能做的优化策略不多。
直接推送的系统，目前就是360消息系统这种，消息类型是消耗型的，并且对于同一个用户并不允许重复消耗,如果需要多终端重复消耗，需要抽象成不同用户。
推的好处是实时性好，开销小，直接将消息下发给客户端，不需要客户端走从接入层到存储层主动拉取.但纯推送模型，有个很大问题，由于系统是异步的，他的时序性无法精确保证。
这对于push需求来说是够用的，但如果复用推送系统做im类型通信，可能并不合适。
对于严格要求时序性，消息可以重复消耗的系统，目前也都是走推拉结合的模型，就是只使用我们的推送系统发通知，并附带id等给客户端做拉取的判断策略，客户端根据推送的key，主动从业务服务器拉取消息。
并且当主从同步延迟的时候，跟进推送的key做延迟拉取策略。
同时也可以通过消息本身的QoS，做纯粹的推送策略，比如一些“正在打字的”低优先级消息，不需要主动拉取了，通过推送直接消耗掉。
哪些因素决定推送系统的效果？首先是sdk的完善程度，sdk策略和细节完善度，往往决定了弱网络环境下最终推送质量选路策略,最基本的一些策略如下：有些开源服务可能会针对用户hash一个该接入区域的固定ip，实际上在国内环境下不可行，最好分配器（dispatcher）是返回散列的一组，而且端口也要参开，必要时候，客户端告知是retry多组都连不上，返回不同idc的服务器。
因为我们会经常检测到一些case，同一地区的不同用户，可能对同一idc内的不同ip连通性都不一样，也出现过同一ip不同端口连通性不同，所以用户的选路策略一定要灵活，策略要足够完善.另外在选路过程中，客户端要对不同网络情况下的长连接ip做缓存，当网络环境切换时候（wifi、2G、3G)，重新请求分配器，缓存不同网络环境的长连接ip。
客户端对于数据心跳和读写超时设置,完善断线检测重连机制针对不同网络环境，或者客户端本身消息的活跃程度，心跳要自适应的进行调整并与服务端协商，来保证链路的连通性。
并且在弱网络环境下，除了网络切换（wifi切3G）或者读写出错情况，什么时候重新建立链路也是一个问题。
客户端发出的ping包，不同网络下，多久没有得到响应，认为网络出现问题，重新建立链路需要有个权衡。
另外对于不同网络环境下，读取不同的消息长度，也要有不同的容忍时间，不能一刀切。
好的心跳和读写超时设置，可以让客户端最快的检测到网络问题，重新建立链路，同时在网络抖动情况下也能完成大数据传输。
结合服务端做策略另外系统可能结合服务端做一些特殊的策略，比如我们在选路时候，我们会将同一个用户尽量映射到同一个room service实例上。
断线时，客户端尽量对上次连接成功的地址进行重试。
主要是方便服务端做闪断情况下策略，会暂存用户闪断时实例上的信息，重新连入的 时候，做单实例内的迁移，减少延时与加载开销.客户端保活策略很多创业公司愿意重新搭建一套push系统，确实不难实现，其实在协议完备情况下（最简单就是客户端不回ack不清数据），服务端会保证消息是不丢的。
但问题是为什么在消息有效期内,到达率上不去？往往因为自己app的push service存活能力不高。
选用云平台或者大厂的，往往sdk会做一些保活策略，比如和其他app共生，互相唤醒，这也是云平台的push service更有保障原因。
我相信很多云平台旗下的sdk，多个使用同样sdk的app，为了实现服务存活，是可以互相唤醒和保证活跃的。
另外现在push sdk本身是单连接，多app复用的，这为sdk实现，增加了新的挑战。
综上，对我来说，选择推送平台，优先会考虑客户端sdk的完善程度。
对于服务端，选择条件稍微简单，要求部署接入点（IDC）越要多，配合精细的选路策略，效果越有保证，至于想知道哪些云服务有多少点，这个群里来自各地的小伙伴们，可以合伙测测。
go语言开发问题与解决方案下面讲下，go开发过程中遇到挑战和优化策略，给大家看下当年的一张图，在第一版优化方案上线前一天截图~可以看到，内存最高占用69G，GC时间单实例最高时候高达3~6s.这种情况下，试想一次悲剧的请求，经过了几个正在执行gc的组件，后果必然是超时… gc照成的接入方重试，又加重了系统的负担。
遇到这种情况当时整个系统最差情况每隔2，3天就需要重启一次~当时出现问题，现在总结起来，大概以下几点1.散落在协程里的I/O，Buffer和对象不复用。
当时（12年）由于对go的gc效率理解有限，比较奔放，程序里大量short live的协程，对内通信的很多io操作，由于不想阻塞主循环逻辑或者需要及时响应的逻辑，通过单独go协程来实现异步。
这回会gc带来很多负担。
针对这个问题，应尽量控制协程创建，对于长连接这种应用，本身已经有几百万并发协程情况下，很多情况没必要在各个并发协程内部做异步io，因为程序的并行度是有限，理论上做协程内做阻塞操作是没问题。
如果有些需要异步执行，比如如果不异步执行，影响对用户心跳或者等待response无法响应，最好通过一个任务池，和一组常驻协程，来消耗，处理结果，通过channel再传回调用方。
使用任务池还有额外的好处，可以对请求进行打包处理，提高吞吐量，并且可以加入控量策略.2.网络环境不好引起激增go协程相比较以往高并发程序，如果做不好流控，会引起协程数量激增。
早期的时候也会发现，时不时有部分主机内存会远远大于其他服务器，但发现时候，所有主要profiling参数都正常了。
后来发现，通信较多系统中，网络抖动阻塞是不可免的(即使是内网)，对外不停accept接受新请求，但执行过程中，由于对内通信阻塞，大量协程被 创建，业务协程等待通信结果没有释放，往往瞬时会迎来协程暴涨。
但这些内存在系统稳定后，virt和res都并没能彻底释放，下降后，维持高位。
处理这种情况，需要增加一些流控策略，流控策略可以选择在rpc库来做，或者上面说的任务池来做，其实我感觉放在任务池里做更合理些，毕竟rpc通信库可以做读写数据的限流，但它并不清楚具体的限流策略，到底是重试还是日志还是缓存到指定队列。
任务池本身就是业务逻辑相关的，它清楚针对不同的接口需要的流控限制策略。
3.低效和开销大的rpc框架早期rpc通信框架比较简单，对内通信时候使用的也是短连接。
这本来短连接开销和性能瓶颈超出我们预期，短连接io效率是低一些，但端口资源够，本身吞吐可以满足需要，用是没问题的，很多分层的系统，也有http短连接对内进行请求的但早期go版本，这样写程序，在一定量级情况，是支撑不住的。
短连接大量临时对象和临时buffer创建，在本已经百万协程的程序中，是无法承受的。
所以后续我们对我们的rpc框架作了两次调整。
第二版的rpc框架，使用了连接池，通过长连接对内进行通信（复用的资源包括client和server的：编解码Buffer、Request/response），大大改善了性能。
但这种在一次request和response还是占用连接的，如果网络状况ok情况下，这不是问题，足够满足需要了，但试想一个room实例要与后面的数百个的register，coordinator，saver，center，keeper实例进行通信，需要建立大量的常驻连接，每个目标机几十个连接，也有数千个连接被占用。
非持续抖动时候（持续逗开多少无解），或者有延迟较高的请求时候，如果针对目标ip连接开少了，会有瞬时大量请求阻塞，连接无法得到充分利用。
第三版增加了Pipeline操作，Pipeline会带来一些额外的开销，利用tcp的全双特性，以尽量少的连接完成对各个服务集群的rpc调用。
时间过长Go的Gc仍旧在持续改善中，大量对象和buffer创建，仍旧会给gc带来很大负担，尤其一个占用了25G左右的程序。
之前go team的大咖邮件也告知我们，未来会让使用协程的成本更低，理论上不需要在应用层做更多的策略来缓解gc.改善方式，一种是多实例的拆分，如果公司没有端口限制，可以很快部署大量实例，减少gc时长，最直接方法。
不过对于360来说，外网通常只能使用80和433。
因此常规上只能开启两个实例。
当然很多人给我建议能否使用SO_REUSEPORT，不过我们内核版本确实比较低，并没有实践过。
另外能否模仿nginx，fork多个进程监控同样端口，至少我们目前没有这样做，主要对于我们目前进程管理上，还是独立的运行的，对外监听不同端口程序，还有配套的内部通信和管理端口，实例管理和升级上要做调整。
解决gc的另两个手段，是内存池和对象池,不过最好做仔细评估和测试，内存池、对象池使用，也需要对于代码可读性与整体效率进行权衡。
这种程序一定情况下会降低并行度，因为用池内资源一定要加互斥锁或者原子操作做CAS，通常原子操作实测要更快一些。
CAS可以理解为可操作的更细行为粒度的锁（可以做更多CAS策略，放弃运行，防止忙等）。
这种方式带来的问题是，程序的可读性会越来越像C语言，每次要malloc，各地方用完后要free，对于对象池free之前要reset，我曾经在应用层尝试做了一个分层次结构的“无锁队列”上图左边的数组实际上是一个列表，这个列表按大小将内存分块，然后使用atomic操作进行CAS。
但实际要看测试数据了，池技术可以明显减少临时对象和内存的申请和释放，gc时间会减少，但加锁带来的并行度的降低，是否能给一段时间内的整体吞吐量带来提升，要做测试和权衡…在我们消息系统，实际上后续去除了部分这种黑科技，试想在百万个协程里面做自旋操作申请复用的buffer和对象，开销会很大，尤其在协程对线程多对多模型情况下，更依赖于golang本身调度策略，除非我对池增加更多的策略处理，减少忙等，感觉是在把runtime做的事情，在应用层非常不优雅的实现。
普遍使用开销理论就大于收益。
但对于rpc库或者codec库，任务池内部，这些开定量协程，集中处理数据的区域，可以尝试改造~对于有些固定对象复用，比如固定的心跳包什么的，可以考虑使用全局一些对象，进行复用，针对应用层数据，具体设计对象池，在部分环节去复用，可能比这种无差别的设计一个通用池更能进行效果评估.消息系统的运维及测试下面介绍消息系统的架构迭代和一些迭代经验，由于之前在其他地方有过分享，后面的会给出相关链接，下面实际做个简单介绍，感兴趣可以去链接里面看架构迭代~根据业务和集群的拆分，能解决部分灰度部署上线测试，减少点对点通信和广播通信不同产品的相互影响，针对特定的功能做独立的优化.消息系统架构和集群拆分，最基本的是拆分多实例，其次是按照业务类型对资源占用情况分类，按用户接入网络和对idc布点要求分类（目前没有条件，所有的产品都部署到全部idc）系统的测试go语言在并发测试上有独特优势。
对于压力测试，目前主要针对指定的服务器，选定线上空闲的服务器做长连接压测。
然后结合可视化，分析压测过程中的系统状态。
但压测早期用的比较多，但实现的统计报表功能和我理想有一定差距。
我觉得最近出的golang开源产品都符合这种场景，go写网络并发程序给大家带来的便利，让大家把以往为了降低复杂度，拆解或者分层协作的组件，又组合在了一起。
Q&AQ1:协议栈大小，超时时间定制原则？移动网络下超时时间按产品需求通常2g，3G情况下是5分钟，wifi情况下5~8分钟。
但对于个别场景，要求响应非常迅速的场景，如果连接idle超过1分钟，都会有ping，pong，来校验是否断线检测，尽快做到重新连接。
Q2:消息是否持久化？消息持久化，通常是先存后发，存储用的redis，但落地用的mysql。
mysql只做故障恢复使用。
Q3:消息风暴怎么解决的？如果是发送情况下，普通产品是不需要限速的，对于较大产品是有发送队列做控速度，按人数，按秒进行控速度发放，发送成功再发送下一条。
Q4:golang的工具链支持怎么样？我自己写过一些小程序千把行之内，确实很不错，但不知道代码量上去之后，配套的debug工具和profiling工具如何，我看上边有分享说golang自带的profiling工具还不错，那debug呢怎么样呢，官方一直没有出debug工具，gdb支持也不完善，不知你们用的什么？是这样的，我们正常就是println，我感觉基本上可以定位我所有问题，但也不排除由于并行性通过println无法复现的问题，目前来看只能靠经验了。
只要常见并发尝试，经过分析是可以找到的。
go很快会推出调试工具的~Q5:协议栈是基于tcp吗？是否有协议拓展功能？协议栈是tcp，整个系统tcp长连接，没有考虑扩展其功能~如果有好的经验，可以分享~Q6:问个问题，这个系统是接收上行数据的吧，系统接收上行数据后是转发给相应系统做处理么，是怎么转发呢，如果需要给客户端返回调用结果又是怎么处理呢？系统上行数据是根据协议头进行转发，协议头里面标记了产品和转发类型，在coordinator里面跟进产品和转发类型，回调用户，如果用户需要阻塞等待回复才能后续操作，那通过再发送消息，路由回用户。
因为整个系统是全异步的。
Q7:问个pushsdk的问题。
pushsdk的单连接，多app复用方式，这样的情况下以下几个问题是如何解决的：1）系统流量统计会把所有流量都算到启动连接的应用吧？而启动应用的连接是不固定的吧？2）同一个pushsdk在不同的应用中的版本号可能不一样，这样暴露出来的接口可能有版本问题，如果用单连接模式怎么解决？流量只能算在启动的app上了，但一般这种安装率很高的app承担可能性大，常用app本身被检测和杀死可能性较少，另外消息下发量是有严格控制 的。
整体上用户还是省电和省流量的。
我们pushsdk尽量向上兼容，出于这个目的，push sdk本身做的工作非常有限，抽象出来一些常见的功能，纯推的系统，客户端策略目前做的很少，也有这个原因。
Q8:生产系统的profiling是一直打开的么？不是一直打开，每个集群都有采样，但需要开启哪个可以后台控制。
这个profling是通过接口调用。
Q9:面前系统中的消息消费者可不可以分组？类似于Kafka。
客户端可以订阅不同产品的消息，接受不同的分组。
接入的时候进行bind或者unbind操作Q10:为什么放弃erlang,而选择go，有什么特别原因吗？我们现在用的erlang？erlang没有问题，原因是我们上线后，其他团队才做出来，经过qa一个部门对比测试，在没有显著性能提升下，选择继续使用go版本的push，作为公司基础服务。
Q11:流控问题有排查过网卡配置导致的idle问题吗？流控是业务级别的流控，我们上线前对于内网的极限通信量做了测试，后续将请求在rpc库内，控制在小于内部通信开销的上限以下.在到达上限前作流控。
Q12:服务的协调调度为什么选择zk有考虑过raft实现吗？golang的raft实现很多啊，比如Consul和ectd之类的。
3年前，还没有后两者或者后两者没听过应该。
zk当时公司内部成熟方案，不过目前来看，我们不准备用zk作结合系统的定制开发，准备用自己写的keeper代替zk，完成配置文件自动转数据结构，数据结构自动同步指定进程，同时里面可以完成很多自定义的发现和控制策略，客户端包含keeper的sdk就可以实现以上的所有监控数据，profling数据收集，配置文件更新，启动关闭等回调。
完全抽象成语keeper通信sdk，keeper之间考虑用raft。
Q13:负载策略是否同时在服务侧与CLIENT侧同时做的 (DISPATCHER 会返回一组IP)？另外，ROOM SERVER/REGISTER SERVER连接状态的一致性可用性如何保证? 服务侧保活有无特别关注的地方? 安全性方面是基于TLS再加上应用层加密?会在server端做，比如重启操作前，会下发指令类型消息，让客户端进行主动行为。
部分消息使用了加密策略，自定义的rsa+des，另外满足我们安全公司的需要，也定制开发很多安全加密策略。
一致性是通过冷备解决的，早期考虑双写，但实时状态双写同步代价太高而且容易有脏数据，比如register挂了，调用所有room，通过重新刷入指定register来解决。
Q14:这个keeper有开源打算吗？还在写，如果没耦合我们系统太多功能，一定会开源的，主要这意味着，我们所有的bind在sdk的库也需要开源~Q15:比较好奇lisence是哪个如果开源？
红蓝对抗之蓝队防守：ATT&CK框架的应用
文章来源：HACK之道 企业大规模数字化转型的浪潮下，各类网络入侵事件频发、APT和黑客团伙活动猖獗，合规性驱动的传统安全防护建设已无法满足需求。
近年来随着各级红蓝对抗行动的开展，企业安全建设正逐步向实战化转型，而MITRE（一个向美国政府提供系统工程、研究开发和信息技术支持的非营利性组织）提出的ATT&CK框架正是在这一过程中能够起到指导性作用的重要参考。
ATT&CK框架在2019年的Gartner Security & Risk Management Summit会上，被F-Secure评为十大关注热点。
ATT&CK是一套描述攻击者战术、技术和执行过程的共享知识库，能够关联已知的黑客组织、攻击工具、检测数据源和检测思路、缓解措施等内容。
ATT&CK能够全面覆盖洛克希德-马丁公司提出的Kill Chain内容，并在此基础上提供更细粒度的攻击技术矩阵和技术详情。
ATT&CK分为三个部分，分别是PRE-ATT&CK，ATT&CK for Enterprise和ATT&CK for Mobile。
其中，PRE-ATT&CK包含的战术有优先级定义、选择目标、信息收集、脆弱性识别、攻击者开放性平台、建立和维护基础设施、人员的开发。
ATT&CK for Enterprise包括的战术有初始化访问、执行、持久化、权限提升、防御逃避、凭据访问、发现、横向移动、收集、命令与控制、数据外传、影响。
这些基于APT组织及黑客团伙的披露信息进行分析梳理的详细信息能够有效指导实战化的红蓝对抗，目前已在多个领域得到较好的应用。
在红蓝对抗中，防守方都可以按照事前、事中、事后三个阶段进行应对，在ATT&CK框架的指导下实现安全体系建立、运营和提升的闭环改进。
一、准备阶段 攻击面评估 攻击面指企业在遭受内、外部入侵时可能的起始突破点或中间跳板，包括但不限于：对外提供业务的Web系统、邮件系统、VPN系统，对内提供服务的OA系统、运维系统、开发环境，员工使用的各类账号、办公终端等。
企业的攻击面是广泛存在的，在企业内进行攻击面评估属于信息收集和脆弱性识别的过程，能够帮助企业在早期应对攻击者入侵活动。
该过程映射到攻击链中属于“侦察”阶段。
由于攻防的不对称性，在红蓝对抗中防守方往往处于弱势，攻击方只需要单点突破即可，而防守方需要建立覆盖所有攻击面的纵深防御体系，很难做到万无一失。
但在 信息收集阶段，是为数不多的防守方占优的阶段，主要原因包括： 1. 攻击方只能通过互联网公开信息（Google、社交网站、Github）或传统社工方式获取部分企业信息，而防守方能够获得完整的企业内部信息，包括网络架构、业务系统、资产信息、员工信息等等，掌握以上信息不但能够梳理潜在入侵点、发现防御中的薄弱环节，还能够结合诱骗或欺诈技术（Deception，如蜜罐），在攻击者能够获取到的信息中埋点，实现类似软件“动态污染”的检测和追踪效果。
2. 攻击面评估能够在特定阶段（如重保时期）通过采取更严格的管控措施降低入侵风险， 通过有限的代价获取最大攻击者入侵难度提升 ，具有很高的投资回报率。
例如，获取VPN通道，相当于突破了企业传统的防护边界，直接获取内网漫游的权限。
在特定情况下，通过增强VPN防护，能够大大缩减攻击者入侵成功的可能性。
突破VPN主要有2种方式，利用VPN服务器本身的漏洞或通过合法VPN账号入侵。
对于第一种方式，关注VPN厂商漏洞披露信息、做好补丁升级管理，能够有效减少大部分威胁；对于利用0day漏洞攻击VPN获取远程访问权限的场景，通过VPN自身日志审计的方式，关联VPN账号新建、变更及VPN服务器自身发起的访问内网的流量，也能够及时发现未知的漏洞攻击行为。
对于第二种攻击VPN合法账号的入侵方式，增加VPN账号的口令复杂度要求、临时要求修改VPN账号口令并增加双因子验证（如绑定手机号短信验证），都可以在牺牲部分用户体验的情况下极大削减攻击者攻击成功的可能性。
ATT&CK框架内所有攻击技术都有对应的攻击目的和执行攻击所需的环境、依赖，对其分解可以提取每项攻击技术适用的攻击对象，参照企业内的资产和服务，评估攻击面暴露情况和风险等级，能够帮助制定有效的攻击面缩减、消除或监控手段。
例如，防守方需要在红蓝对抗前检查企业内部的共享目录、文件服务器、BYOD设备是否符合安全基线要求，是否存在敏感信息，并针对这些内容设定合规性要求和强制措施，以缩减该攻击面暴露情况。
综上，ATT&CK框架可以帮助防守方了解攻击目标、提炼攻击面并制定攻击面缩减手段，同时也能够通过攻击面评估为后续增强威胁感知能力、总结防御差距、制定改进方案提供参考标准。
威胁感知体系建立 传统的安全防护和管控措施存在的主要问题在于没有全景威胁感知的体系，无法及时有效地监测威胁事件、安全风险和入侵过程。
威胁感知体系的建立，可以有效地把孤立的安全防御和安全审计手段串联起来，形成完整的企业安全态势，为防守方实现实时威胁监控、安全分析、响应处置提供基础。
建立威胁感知体系主要包括以下准备工作：1.数据源梳理： 数据是实现安全可见性的基础元素，缺少多维度和高质量的数据会严重影响监控覆盖面；同时，很多企业会为了满足网络安全法、等保标准等法律和标准要求存储大量设备、系统和业务日志数据。
因此，在数据源的规划、管理上，由威胁驱动的数据源需求和由合规驱动的日志数据留存，存在匹配度低、使用率低、有效性低的诸多问题，需要防守方加以解决。
* We can’t detect what we can’t see. 在进行数据源规划时，需根据企业实际存在的攻击面、威胁场景和风险情况进行设计。
例如：针对员工邮箱账号可能会遭受攻击者暴力破解、泄露社工库撞库的风险，需要采集哪些数据？首先需要考虑企业实际的邮件系统情况，比如使用自建的Exchange邮件服务，需要采集的数据包括：Exchange邮件追踪日志、IIS中间件日志、SMTP/POP3/IMAP等邮件协议日志。
其次还需要具体考虑攻击者是通过OWA访问页面爆破？还是通过邮件协议认证爆破？还是通过Webmail或客户端接口撞库？不同的企业开放的邮箱访问方式不同，暴露的攻击面和遭受的攻击方法也有所区别，需要根据实情梳理所需的数据源。
在数据源梳理上，由于涉及到的威胁类型、攻击方法众多，考虑周全很困难，可以通过参考ATT&CK框架选取企业相关的攻击技术，统计所需的数据源类型，并梳理数据源采集、接入优先级。
关于数据源优先级筛选，2019年MITRE ATT&CKcon 2.0会议上Red Canary发布的议题：Prioritizing Data Sources for Minimum Viable Detection 根据总体数据源使用的频率做了Top 10排序，如下图所示： 该统计结果并未考虑企业实际攻击面范围、数据源获取的难易程度等，不应生搬硬套照抄。
但在大部分情况下可以考虑先构建包括网络镜像流量、终端行为审计日志、关键应用服务日志在内的基础数据源的采集规划，再通过实际的检测效果增强补充。
2. 检测规则开发：大数据智能安全平台（或参考Gartner所提的Modern SIEM架构）已逐步取代传统的SIEM产品，成为企业威胁感知体系的核心大脑。
传统的攻击检测方法大多是基于特征签名（Signature），采用IOC碰撞的方式执行，在实际攻防对抗过程中存在告警噪音过多、漏报严重、外部情报数据和特征库更新不及时等问题，且在防守方看来无法做到检测效果的衡量和能力评估。
因此，新的检测理念需要从行为和动机出发，针对攻击者可能执行的操作完善审计和监控机制，再采用大数据关联分析的方式去识别攻击活动。
ATT&CK框架在这里就起到了非常重要的参考作用，框架中的每项攻击技术，知识库都描述了相应的检测手段和过程，以T1110暴力破解为例，其Detection描述如下图所示。
虽然没有抽象出具体检测方法、检测规则，但提炼出了需要监控的设备以及能够提炼攻击痕迹的日志。
参考这部分描述，防守方能高效的通过相关资料收集、内部攻击技术模拟、特征提炼等方式完成检测方法和检测规则的开发、部署、测试。
此外，高级持续性威胁（APT）使用了较多的白利用技术，无法有效区分攻击者和普通工作人员。
但通过开发检测规则对数据源进行过滤提炼，打上技术标签，后续再综合所有异常行为能够发现此类攻击活动。
这样再与传统的检测方法结合，就提供了更加有效的补充手段。
综上，威胁感知体系的建立，需要通过数据源梳理和检测规则开发来完成基础准备工作，ATT&CK框架可以帮助防守方快速了解所需数据源、并协助开发对应的检测规则，使防守方脱离安全可见性盲区，实现安全防护能力的可量化、可改进。
内部模拟对抗 为摸清目前网络安全防御能力并找出薄弱点，部分企业会进行内部红蓝对抗模拟演练，ATT&CK知识库在模拟红队攻击、组织内部对抗预演上具有非常高的参考价值。
1.红队技术指导：ATT&CK框架包含了266种攻击技术描述，模拟红队可以借鉴其中部分技术进行特定战术目的的专项测试或综合场景测试。
在开展内网信息收集专项测试时，可以通过参考并复现“发现”、“收集”战术目的下的攻击技术，对内网暴露的攻击面逐一测试；在开展模拟场景演练时，可以挑选不同的战术目的制定模拟攻击流程，从矩阵中选择相关技术实施。
以典型的红队钓鱼攻击场景为例，攻击技术链包括：钓鱼 -> hta执行 -> 服务驻留 -> 凭证获取 -> 远程系统发现 -> 管理员共享，如下图红色链路所示。
2. 蓝队效果评估：内部模拟对抗是企业防守方检查实际威胁感知能力的最佳手段，对蓝队来说具有查漏补缺的效果。
攻击行为是否被记录、检测规则是否有效、有无绕过或误报、攻击面梳理是否遗漏、威胁场景是否考虑充分等很多问题只有在实际测试中才会暴露。
同时，防守方也可以通过模拟演练提炼极端情况下的缓解预案，包括：临时增加防御拦截措施、增加业务访问管控要求、加强人员安全意识教育和基线管理等。
综上，内部模拟是红蓝对抗实战阶段验证所有准备工作有效性的手段，作为大考前的模拟考，对防守方具有很大的查漏补缺、优化完善的作用，而ATT&CK框架在这个阶段，对模拟红队攻击、协助蓝队查找问题都起到了参考作用。
二、开展阶段 准备过程越充分，在实际红蓝对抗行动开展阶段对防守方来说就越轻松。
经过验证的威胁感知体系在这里将起到主导作用。
资产风险监控 除了封堵、上报潜在的红队攻击IP外，对于已突破边界防护进入内网漫游阶段的攻击者，基于ATT&CK框架能够有效识别资产（终端/服务器）风险，发现疑似被攻陷的内网主机。
通过为每个资产创建独立的ATT&CK主机威胁分布矩阵图，汇聚该主机上近期被检测到的所有攻击技术活动，然后根据该矩阵图上所标注的攻击技术的分布特征训练异常模型，监控主机是否失陷。
异常模型从以下三个维度识别攻击： 1.攻击技术分布异常：多个战术下发生攻击、某个战术下发生多个不同攻击等。
2. 攻击技术数量异常：主机上检测到大量攻击技术，与基线对比偏差很大。
3. 特定高置信度失陷指标：主机上触发了高置信度规则检测到的高风险告警（传统的Trigger机制）。
以下图为例，主机短时间内触发一系列“发现”战术下的攻击技术，这在日常运维中是较为少见的，与该主机或同类型主机基线对比偏差非常大。
在受害主机被控制后可能会执行大量此类操作，故该机器风险很高，判定为失陷/高危资产。
可疑进程判定与溯源 根据采集的终端行为日志（包括：进程活动、注册表活动、文件活动和网络活动），可以通过唯一进程ID（GUID）进行父子进程关联操作。
当发现可疑进程活动时，能够回溯该进程的进程树，向上直到系统初始调用进程，向下包含所有子进程，并且为进程树中所有可疑进程添加ATT&CK攻击技术标签，如网络请求、域名请求、文件释放等丰富化信息，帮助防守方的安全分析人员判断该进程是否可疑并及时采取处置措施。
以下图为例，发现可疑进程后溯源其进程树，其中标记了感叹号的子进程为命中了ATT&CK攻击技术的进程，无感叹号的子进程也属于该可疑进程树下，有可能是攻击者利用的正常系统进程或规避了检测规则导致未检出的进程。
通过该进程树展示的信息，可以直观发现wscript进程及其派生的powershell进程存在大量可疑行为，这些进程信息也为后续联动终端防护软件处置或人工上机排查处置提供了充足的信息。
应急响应对接 在发现失陷资产、溯源到可疑进程后可导出其进程树上的进程实体路径、进程命令行、进程创建文件、进程网络连接等信息提交给应急响应组进行清除工作。
应急响应组通过以上信息可以快速在主机上处置并开展入侵路径分析，通过回溯攻击者入侵植入木马的手段，进一步排查是否存在数据缺失、规则缺失导致的攻击漏报；并通过关联所有具有相似行为的终端，确认是否存在其他未知失陷资产。
以上基于ATT&CK框架建立的资产风险监控和可疑进程判定方法，能够有效地在红蓝对抗过程中及时发现攻击者攻击成功的痕迹，并为溯源和应急响应处置提供数据支撑。
而这些都脱离不了以威胁感知体系为核心的蓝队建设思路，更多与ATT&CK框架适配的应用方法也会在后续不断丰富、增强。
三、复盘阶段 防御效果评估 在红蓝对抗结束复盘阶段，防守方对防御效果的评估是非常重要的环节。
具体包括以下内容： 安全设备漏报分析：结合攻击方提供的报告，把各个攻击类型归属到相应的安全检测设备，查看相关设备的告警与报告中的攻击过程是否匹配，分析当前安全设备检测能力，较低检出率的设备需要后续协调厂商优化、更新规则等，以加强完善。
规则误报调优：在红蓝对抗开展阶段，为了确保对攻击方攻击过程的全面覆盖检测，通常会采用限制条件较宽松的规则检测模式，以防漏报对防守方造成的失分影响。
例如，对暴力破解场景，触发告警的连续登录失败请求阈值可能设定的较低；对Webshell植入场景，可能对所有尝试上传动态脚本文件的行为都做监控或拦截，以防攻击者通过一些编码、混淆的方式绕过特征检测等。
这些限制条件宽松的检测规则，在红蓝对抗过程中能够尽量减少攻击漏报，具有比较好的效果；但同时，由于限制不严导致的告警噪音也会随之增加。
在红蓝对抗结束复盘过程中，需要对产生误报的数据和误报原因进行统计分析，完善检测规则逻辑、边界条件限制，配置适当的白名单过滤，为后续能够日常运营提供更具备可操作性和更实用的威胁检测规则。
攻击面再评估和数据可见性分析：在红蓝对抗准备和红蓝对抗开展阶段，防守方和攻击方分别进行了攻击面评估、攻击目标信息收集的工作，因此在复盘阶段可以通过对比双方掌握的攻击面信息和攻击目标的选择，来挖掘是否存在先前遗漏的边缘资产、未知攻击面，通过攻方视角查漏补缺。
同时对遗漏的攻击面可以做相关的数据源需求分析，补充缺失的数据可见性和威胁感知能力。
防御差距评估与改进：针对红蓝对抗中发现的薄弱环节，防守方可以提炼改进目标、指导后续的安全建设工作。
由于不同企业存在的攻击面差异性较大，重点关注的核心资产、靶标也有所差别，在准备过程中可能根据优先级选择了比较关键的几个领域优先开展，而通过红蓝对抗发现的其他薄弱环节，为后续开展哪些方向的工作提供了参考。
例如，重点加强生产环境安全防护的，可能忽略了员工安全意识培训，导致被攻击者钓鱼的方式突破入侵；重点关注网站安全的，可能忽略了服务器存在其他暴露在外的端口或服务，被攻击者通过探测发现，利用已知漏洞或0day漏洞控制服务器绕过。
结合ATT&CK框架补充对应的数据源和攻击技术检测手段，可以快速补足这方面的遗漏。
防御效果评估是红蓝对抗复盘阶段重要的总结过程，也为后续持续优化改进提供参考。
在这里ATT&CK框架起到的作用主要是统一攻防双方语言，将每一个攻击事件拆分成双方都可理解的技术和过程，为红蓝对抗走向红蓝合作提供可能。
网络空间资产测绘
网络空间测绘网络空间包含实体人物层、虚拟角色层、逻辑网络层、物理网络层与地理层，其中，网络空间测绘的主要研究对象为物理网络层。
近年来，网络空间作为人类生产生活的第二类生存空间，其软硬件系统与信息数据被视为国家重要的战略资源。
网络空间测绘技术通过探测识别、实体定位、深度关联与层级映射，绘制“第五空间”的“底图”，以建立高效网络资产安全检测体系，对管理网络空间、应对安全事件与维护国家网络空间主权具有重要意义。
网络空间测绘技术涉及网络探测、协议分析、规则匹配、拓扑分析、大数据、应用安全与可视化表达等领域。
本文将从网络资产探测与拓扑结构分析两方面，阐述相关技术及其面临的挑战。
在网络空间测绘的研究中，美国率先启动相关研究与应用。
我国也已部署与研究网络空间测绘方向，如公安部第一研究所设计研发的“网络资产测绘分析系统”，通过收集互联网资产数据与指纹，实现网络空间资产检索、分析与监控，结合漏洞与厂商信息进行漏洞统计分析，旨在为国家重点行业与部门提供全面的网络资产安全态势，增强其应对威胁关键信息基础设施网络攻击的能力。
网络空间测绘系统自底向上分为全维探测层、接引汇聚层、融合分析层与综合呈现层。
全维探测层负责生成探测策略、下发探测任务，为测绘系统提供数据支撑。
接引汇聚层负责对探测与第三方数据进行汇聚、清洗、抽取与校验，提高数据融合分析结果的可信性。
融合分析层负责拓扑结构还原与分析、资产属性识别与重要目标画像，是系统核心功能的实现部分。
综合呈现层则面向全球用户，定制化展示网络空间“地形地貌”，提供数据查询与订阅服务。
网络资产探测分为主动探测、被动探测与基于搜索引擎的非侵入式探测。
网络资产探测主要获取目标主机的设备属性与应用属性信息，如IP存活性探测、端口/服务探测、操作系统探测、流量采集、别名解析与DNS探测、应用类型探测等。
网络资产识别包括设备组件识别、应用组件识别与业务类型推断，通常通过资产指纹比对实现。
设备组件识别与应用组件识别分别通过与网络设备组件指纹库与网络应用组件指纹库进行指纹比对，识别目标主机的设备类型、设备厂商、设备品牌、设备型号等设备属性与Web服务器软件、Web脚本语言、服务类型及相应版本型号等应用属性。
业务类型推断则基于资产探测数据，结合DNS信息、漏洞库与IP地理信息库等资源，建立资产多层级关联模型，识别网络资产的业务类型。
网络拓扑结构还原是利用IP路径信息、路由器配置文件与BGP路由表等数据，还原网络的IP级、路由器级、PoP级与AS级拓扑结构。
拓扑结构还原与分析包括边界节点识别、骨干节点识别与节点关系推理。
未来几年，IPv6技术的普及与物联网设备的爆发，将为网络空间测绘带来新的挑战与机遇。
面对IPv6技术带来的挑战，IPv6地址空间预测技术利用地址分布与运营规律，通过收集种子地址、建模与地址生成算法，提高活跃IPv6地址的发现效率。
对于物联网设备的识别，传统技术需结合人工智能与机器学习，以提高设备识别的效率与准确率。
未来网络资产测绘预计将朝着内网、专网资产管理的广泛应用、网络资产探测与识别的自动化与准确率提高以及网络空间拓扑分析的多维度与多层次发展。
网络空间测绘技术将不断进步，以满足日益增长的网络空间安全需求。
