NLP從入門到放棄——處理威脅情報
0x00 前言：
事情源於之前不太認真的認真回答，見：知乎使用者：NLP 在威脅情報中有哪些應用？，於是乎就有人私信問了，實際上對於這一部分我也是剛剛才開始接觸，至於這個需求是怎麼來的，實際上有兩個原因，第一個原因是因為boss的強迫症：告警推送全都是要求用自然語言表達，第二個原因是因為威脅情報的分類問題，我們在捕獲威脅情報的時候，共識是使用爬蟲去爬取有對應訊息的源（源這裡實際上是經過篩選的，篩選的過程等以後有時間再說），這個時候問題就來了，國內的源要麼訊息滯後要麼不提供RSS的介面（xx廠商為首），而國外的源相反，訊息更新的很快，有RSS和郵件推送，甚至有些資訊做到了json推送，這個時候另一個問題就來了，推送個英語過來的還好，這要是推送個思密達這種，沒有語言功底的人還確實看不懂，所以這個時候想到了用NLP（自然語言處理）來解決情報處理的問題。
0x01 確定要收集的資訊：
我們現在假設這樣一個場景：老大讓你收集一些關鍵元件的漏洞披露情況，如果有高風險的話，立馬透過IM、郵件的形式推送到老大的面前。拋開規劃不談，這種針對特定元件的漏洞收集工作實際上是比較繁瑣的一件事兒，因為你也不知道什麼時候爆發什麼漏洞，但是我們還是有些特定的收集技巧，我們按照披露的灰度來對源進行分類：
漏洞發現過程：這個時候最好的選擇是oss-sec下面的bugtraq和oss mailing-list，或者是openwall mailing-list，如果你曾經給redhat這種提交過漏洞，也可以混到他們的郵件列表中去獲取相對應的情報資訊
漏洞披露之後：最直接的方法是直接去爬去每天更新的cve列表，mitre有介面可以操作
完成這個過程之後，實際上你就可以去編寫爬蟲了，至於編寫爬蟲的過程，略，大概爬完就是這種效果：
{
“id”
：
“CVE-2018-6439”
，
“cvss”
：
{}，
“seen_wild”
：
false
，
“date_created”
：
“2018-12-03T00：00：00”
，
“description”
：
“A Vulnerability in the configdownload command of Brocade Fabric OS command line interface （CLI） versions before 8。2。1， 8。1。2f， 8。0。2f， 7。4。2d could allow a local attacker to escape the restricted shell and， gain root access。”
，
“reference”
：
［
{
“name”
：
“https：//www。broadcom。com/support/fibre-channel-networking/security-advisories/brocade-security-advisory-2018-730”
，
“type”
：
“UNKNOWN”
，
“external_source”
：
“CONFIRM”
，
“href”
：
“https：//www。broadcom。com/support/fibre-channel-networking/security-advisories/brocade-security-advisory-2018-730”
}
］，
“products”
：
［］，
“mitre”
：
“https：//cve。mitre。org/cgi-bin/cvename。cgi？name=CVE-2018-6439”
，
“exploit”
：
［］
}
0x02 機讀轉人讀
這個時候你就能大概瞭解到了這個漏洞的一些資訊，but，你只知道了這個漏洞的資訊，但是你並不知道這個漏洞是否值得響應，那麼什麼樣的漏洞資訊值得你去響應呢，一般情況下這個值得響應是跟資產相關、漏洞危害、在野利用、是否披露等多個方面進行評估之後才能得出是否需要修復的決策的，這顯然不是威脅情報生產團隊需要考慮的（畢竟有幹實事兒的SRC存在），但是情報側要提供資訊可以幫助他們決策，以上面這個漏洞而言，我們需要關注的是描述這裡：
A Vulnerability in the configdownload command of Brocade Fabric OS command line interface （CLI） versions before 8。2。1， 8。1。2f， 8。0。2f， 7。4。2d could allow a local attacker to escape the restricted shell and， gain root access。
我們在這裡使用自動化的方法完成對這段話的處理，處理的目的在於：
（1）提高情報的可運營效率，也就是說人話讓運營人員能操作
（2）提高情報指向性，方便運營人員排查資產是否受影響
（3）聯動IM，提高情報推送的及時性
（4）也可以和資產系統進行聯動，確定受影響的元件範圍，降低修復漏洞的SLA
我們使用簡單的分詞結合之前使用cpe和cwe等資料作為訓練樣本獲得的資料對漏洞告警資訊進行處理，並且將告警資訊漢化，舉個例子：
# coding： utf-8
import
nltk
import
mtranslate
from
nltk。tag
import
pos_tag_sents
fintels
=
［］
vul_describes
=
json
。
loads
（
cve_spider_list
）
for
vul_describe
in
vul_describes
：
chn_u
=
mtranslate
。
translate
（
vul_describe
［
“description”
］，
“zh-cn”
）
words
=
nltk
。
word_tokenize
（
vul_describe
［
“description”
］）
affect_list
=
mach_learn
（
cpe_list_sample
（））
# 訓練樣本返回的元件名稱規則
version_list
=
mach_learn
（
cpe_version_sample
（））
# 訓練樣本返回的元件版本規則
severity_list
=
mach_learn
（
severity_sample
（））
# 訓練樣本返回的漏洞型別規則
res
=
nltk
。
tag
。
pos_tag
（
words
）
affect
=
“”
version
=
［］
severity_list
=
［］
for
word
，
pos
in
res
：
if
pos
in
affect_list
：
t_words
=
word
+
“ ”
affect
+=
t_words
elif
pos
in
version_list
：
version
。
append
（
word
）
elif
pos
in
severity_list
：
severity_list
。
append
（
word
）
fintel
=
{
“description”
：
chn_u
，
“affect”
：
affect
，
“version”
：
version
，
“reference”
：
vul_describe
［
“reference”
］，
“cve_id”
：
vul_describe
［
“cve_id”
］，
“severity”
：
severity_list
}
fintels
。
append
（
fintel
）
（
fintel
）
處理過後得到的資訊就變得簡單多了：
OK，這個時候，我們就可以聯動IM了，因為各家IM都不盡相同，所以這個就看各家的SDK就能解決這個問題，最後推送的效果呢就是這樣：
這樣，安全運營人員就可以根據你的情報進行響應了。
0x03 小結：
以上的問題其實從操作的角度上來看並不難操作，關鍵是在於NLP技術如何幫助去自動化處理一些威脅情報資訊來方便人去運營，畢竟情報收集很大一定程度上都是根據公開的資訊，有很多情況下都是需要去處理海量的資訊，這個時候自動化識別、NLP、OCR這些技術就能夠提高我們的處理效率，減少因為情報造成的時機延誤。畢竟運營哥哥和姐姐也是很辛苦的，掃描器、監控、IDS這些東西都會告警，都要去響應，這時候你要是再給他來一堆不能響應的情報，他會拿一把40米長的大刀然後讓你先跑39米。
另外打一個小廣告，我和幾個朋友建了個威脅情報技術和運營的交流群，歡迎甲方的安全情報運營人員和乙方的威脅情報分析大佬們加入（現在已經有一些一線網際網路廠商的大佬和top1、2、3威脅情報廠商的資深分析師入住），由於小弟最近有點忙，只要看到了就會同意進群，數量有限。如果看不到二維碼的話，微信搜尋elknot即可，加的時候麻煩備註一下id和所在企業，因為是機器人稽核所以是自動的。
https：//
u。wechat。com/MBlOyYc9Mv
lmUqVVxBp3kmc
（二維碼自動識別）