私の現場では、脆弱性対応に関するフローや対応策が確立できていません。
気づいた人ベースで発信され、深刻度合いで対応するかしないかをお客様が決定します。
この、「気づいた人ベース」をしっかり運用フローに乗せることを考えて行きたいと思います。
そもそも脆弱性対応をする意義
脆弱性をついたサイバー攻撃により、企業の重要な情報が外部に漏洩することや、サイト停止に伴う売上や信頼の低下を防ぐことだと思います。
攻撃側を考えると、脆弱性発生後に脆弱性の内容を元に、攻撃プログラムが作成されるため、一定の期間は要します。
この間に、攻撃を未然に防ぐことが重要になります。なので、脆弱性情報の収集は必須となってきます。
統計的には、実際に攻撃までに繋がる脆弱性は2%にも満たず、攻撃プログラムが公開されるまでの日数は、２週間以内が50%を占めているそうです。
なので、全ての脆弱性を対応するのは非効率であって、深刻な脆弱性を見極めて対応していくこと重要となってきます。
パッチマネジメント
システム構成を把握している前提で、構成要素ごとに関連する脆弱性情報を早く検知し、影響範囲の特定とリスクの分析によって適用の緊急性と対応用ひを判断し、判断結果を元に対応する一連の流れ。
❶検知
ベンダ、有識者、業界団体などから発信される脆弱性情報を収集し、システム構成要素に対する影響を評価
❷判断
脆弱性に起因するリスクの大きさと攻撃手法の容易性を分析し、対応の緊急度と対応要否を決定する
❸対応
対策方法と実施時期を確定し、攻撃を受ける前に、脆弱性によるリスクを下げる。
対策
検知
検知の部分に関しては、ベンダ（AWS）の脆弱性情報サイトがあるのでそちらで、通知機能をSlack通知で検知できるようにしている。
その他は、Twitterの有識者やベンダのフォローをして、自主収集する形をとっている。
このSlackへ全員を招待させることで、検知に関しては解決すると思っている。
全員に通知する必要はないかもしれないが、セキュリティ担当が確立されていないので、一旦全員に通知。
判断
判断に関しては、緊急性判断は、CVSSを用いた考えが一般的。
CVSSとは、脆弱性に対するオープンで汎用的な評価手法、及び指標を指します。
1.0〜10.0の数値指標となっていて、7.0以上が緊急度：Highに値します。
緊急度：Highであり、他社でも被害が出ている状況であると、即座に対応が必須な状況であります。
だが、大体的に報道される脆弱性の悪用は、直接的被害に留まらず風評被害などのに二次的な被害につながりやすいです。
実際にあった脆弱性
sudo
CVSS 7.0 High
他社影響はなしだけど、ベンダから情報発表はあり
要確認の脆弱性となる。
対応
対応策としては、パッチ適用、ワークアラウンド（設定変更やWAFによる通信遮断）、一時的なサービス停止などがあります。
これらを比較して、最良な選択をすることが大事になってくる。
それでも対応結果が追跡しきれず、時間がかかってしまう場合は、システムごとの対応状況の一元管理が必要となってきます。
資産管理台帳をもとに、脆弱性対応の指示や報告を実施して、常に最新情報を集約できるようにしておくこと。
情報集約度、情報鮮度、検索容易性の観点から管理や統制パターンが分かれるそうです。
・情報集約度
システムの構成情報が集中管理されているか
・情報鮮度
構成情報が常に最新の状態が保たれているか
・検索容易性
脆弱性を検知後、迅速に対象となるシステムを一覧化できるか
踏まえて
現状、脆弱性の集約から判断や対応に関しては有識者の方で、なんとか実施できているが。
いない時を考えると恐ろしいので、運用フローには乗せて行きたい。
メインシステムは、WAFの導入をしているので大半は大丈夫である気がするが、抜け道もある気がする。
情報集約度の観点からすると、システム構成の集中管理はできていない状況なため、大規模な脆弱性が起きた場合に、迅速に対応する体制はできていない。
まず、手をつけるとしたら、この「システム構成の集中管理」が第一優先だと思いました。