tjinjin's blog

インフラ要素多めの個人メモ

脆弱性情報の見方と付き合い方

この記事の目的

昨今、Shellshockに始まり、Heartbleed、POODLE、FREAKと脆弱性情報がいろいろ出ていますね。そういった情報をこれまではtwitterなどを通して仕入れてきたのですが、このタイミングで一次情報にもきっちり当たれるようになっておきたいと思い、脆弱性情報の見方や収集の仕方をまとめておきたいと思います。せっかくまとめたので、初心者向け情報として公開し、またおかしな点のご指摘や更に有益な情報をスペシャリストの方々にご教示いただければ助かります。

脆弱性情報とは?

CVEって?

脆弱性にはよくCVEというuniqな番号が振られます。これは米国政府の支援を受けた非営利団体のMITRE社というところが管理している番号で、脆弱性情報を一元的に管理できるようになっています。日本で運用されているJVNという識別子もCVEと関連付けされており、情報をたどることができます。

CVEはSCRAPという標準仕様の一部

CVEはSCRAP(Security Content Automation Protocol)というNISTが開発したセキュリティ仕様の一部です。SCRAP自体は大きく6つの仕様から成り立っています。(それぞれの詳細についてはIPAの解説記事がおすすめです)

脆弱性を識別するためのCVE

(Common Vulnerabilities and Exposures:共通脆弱性識別子) CVEのフォーマットは「CVE-西暦-連番」となっていて、CVE Editorial Boradという機関が脆弱性を評価し割り当てています。よくJVNという言葉も聞きますが、IPAJPCERT/CCが共同で運営しているものでCVEとの整合を取るようになっています。

セキュリティ設定を識別するためのCCE

(Common Configuration Enumeration:共通セキュリティ設定一覧)

製品を識別するためのCPE

(Common Platform Enumeration:共通プラットフォーム一覧)

脆弱性の深刻度を評価するためのCVSS

(Common Vulnerability Scoring System:共通脆弱性評価システム)

チェックリストを記述するためのXCCDF

(eXtensible Configuration Checklist Description Format:セキュリティ設定チェックリスト記述形式)

脆弱性やセキュリティ設定をチェックするためのOVAL

(Open Vulnerability and Assessment Language:セキュリティ検査言語)

サーバ管理者としてはその脆弱性の影響範囲がどこなのかだと思います。そういう意味だとCVSSの見方を理解しておくとよいと思います。

CVSSの見方

CVSSはベンダーに依存しない共通の評価方法です。

主な基準

基本評価基準 (Base Metrics)

機密性、完全性、可用性を脅かすような影響を判断し、数値化されます。固定される数値です。

現状評価基準 (Temporal Metrics)

上記に加えて、攻撃手法が確立されていることや対応状況によって変化します。

環境評価基準 (Environmental Metrics)

実際にどういうようにその製品が利用されているかなどを加味した結果の数値です。製品利用者が脆弱性への対応を決めるために評価する基準となります。

JVNのサイトを確認すると主に基本値が載っているのでそこを確認するとよさそうです。

評価基準の計算方法

6つの基準を総合し判断されます。

AV :攻撃元区分 (Access Vector)

どこから攻撃されるかです。値としてはローカル、隣接、ネットワークがあります。隣接がわかりにくいですが、ローカル IP サブネット、ブルートゥースIEEE 802.11など から影響を受ける場合です。(あまり見たことないですね)。ネットワーク越しの攻撃が一番注意するところですかね。ローカルだと、Firewallなどでそもそもアクセスできなければ問題ないと判断できるかと思います。

AC :攻撃条件の複雑さ (Access Complexity)

攻撃が簡単かってことです。高・中・低でわかれており、低だと簡単ということです。一刻も対応しないとまずいですね。

Au :攻撃前の認証要否 (Authentication)

認証が何段階あるかです。複数・単一・不要があり、複数はMFAをイメージするとよさそうです。

C :機密性への影響 (情報漏えいの可能性、 Confidentiality Impact )
I :完全性への影響 (情報改ざんの可能性、 Integrity Impact )
A :可用性への影響 (業務停止の可能性、 Availability Impact )

下3つは文字通りですね。なし・部分的・全面的があります。SLAとかに関わってくる部分なので全面的の場合は早急な対策が必要そうです。

これらの項目ごとに数値が決められておりそれを計算することでbase Metricsが算出されます。一応計算式書いておきますが、私もわかってないです。

影響度 = 10.41×( 1 - ( 1 - C )×( 1 - I )×( 1 - A ) ) …式(1)

攻撃容易性 = 20×AV×AC×Au …式(2)

f(影響度) = 0(影響度が0の場合) , 1.176(影響度が0以外の場合) …式(3)

基本値 = ((0.6× 影響度)+(0.4× 攻撃容易性 )-1.5)×f(影響度) …式(4)
       (小数点第 2 位四捨五入)

数値の目安

数値についてはある程度目安があるようで、IPAの資料に記載がありました。(記事が2007年なので古いかもしれません)

深刻度 CVSS基本値 脆弱性に対して想定される脅威
レベルIII (危険) 7.0~10.0 ・リモートからシステムを完全に制御されるような脅威
・大部分のデータを改ざんされるような脅威
・例えば、OSコマンド・インジェクション、SQLインジェクション、バッファオーバフローによる任意の命令実行など
レベルII (警告) 4.0~6.9 ・重要な情報が漏洩するような脅威
・サービス停止に繋がるような脅威
・例えば、アクセス制御の回避、全てのシステムが停止するようなサービス運用妨害(DoS)など
・その他、レベルIIIに該当するが再現性が低いもの
レベルI (注意) 0.0~3.9 ・システムの一部に被害が発生するような脅威
・攻撃するために複雑な条件を必要とする脅威
・例えば、クロスサイト・スクリプティング、ディレクトリ・トラバーサルによる一部の情報漏えい、一部のシステムが停止するようなサービス運用妨害(DoS)など
・その他、レベルIIに該当するが再現性が低いもの

目安として使うといいかと思います。

脆弱性情報の収集方法

どうやってセキュリティ情報を収集するか

メーリングリストに登録する

各製品やディストリビューションがそれぞれでアップデート情報を通知しているメーリスなどがあります。そこに登録するのが、確実ですがメールなので面倒な気はしています。

セキュリティフィードを購読する

フィードで情報収集する方法も。ただ、RSSに対応してないものもあるので限られるかも。情報の即時性が微妙なものもあるので、他の方法と併用しないと厳しいかも。

セキュリティクラスタtwitterでフォローする

なんだかんだでこれが楽です。情報の偏りがあるとは思いますが、脆弱性情報をすぐにキャッチアップできます。

セキュリティパッチをCIで確認する

KAIZENがセキュリティパッチの適用をCIで回しているみたいです。今も同じフローなんでしょうかね。サービスを長い期間運用することを考えると、セキュリティアップデートを当て続ける必要があります。最近だとブルーグリーンデプロイメントという考え方も出てきており、環境を複数用意し、アップデート済みの環境に切り替える方法が綺麗な気がしています。

githubをcheckする

OSSの場合はgithub上でで開発している場合もあります。そこで判断できるかも?

脆弱性の対応

どうやって適用するか

適用しなくてもいいか判断する

この脆弱性はネットワークを介した脆弱性で、うちはfirewallで絞ってるから〜というようなことで適用しないことということもありだと思います。管理者の判断の結果適用しないとなったという経緯を管理しておく必要はありそうです。

検証して手動でアップデートする

ステージング環境等があれば、そこで検証して問題ないと判断した結果適用するという選択肢もありそうです。ただ、サービスを複数抱えている場合その分検証が必要になり労力が必要になりそうです。

CIで自動アップデートする

上述のKAIZENの例ですね。すごいなぁと思う所です。テストの信頼性が高いから出来る賜物なのかなと。

 

個人的な考え

セキュリティアップデートは自動で行いたいと思ってます。現在はアップデート情報確認して、影響を判断して〜というようなことやってますが正直面倒だなと。判断の結果適用しないとなったとして、当時は良くてものちのちアップデートが必要になったときに製品のバージョンが大きく変わっており、yak sharving状態になりがちです。アップデートを日頃から自動でやっておくことができれば、運用がすごい楽な気がしています。ただ、アップデートした後の動作保証をどうするかという話があると思います。E2Eテストがあれば、動作保証がある程度担保されるのでいいのかなと思っているところです。また、ブルーグリーンデプロイという形で、複数環境を用意して何らかの方法で確認ができたら切り替える。で最悪問題が発生したら切り戻すという運用がいいのかなぁと思う所です。2つ環境を用意するというのは、コスト面で難しい場合があるのでそこは悩ましい所ですね。nanapiでdockerを使ったブルーグリーンデプロイの記事がありましたが、あのような形がいいのかな。

参考リンク