「脆弱性」という言葉は取っつきにくい～脆弱性対策のいろは～
前回は、ちょっと軽い(？) お話でしたので、今回はちょっと真面目な話で「脆弱性」の話です。
端末でいえば毎月１回Windows Updateを実施すると、端末のWindowsOSやMicrosoft製品の脆弱性を修正するセキュリティパッチが適用されますが、今回の話はこの「脆弱性」についてです。
13792
さて、この「脆弱性」、セキュリティに関わる人であれば知っているとは思いますが、今回のコラムではソフトウェア（HW製品のファームウェア含む）に作られてしまったセキュリティホールのことに限定します。
で、この脆弱性を攻撃するとセキュリティ事故が発生するというわけです。
で、ソフトウェアといってもいろいろあり、Windows、Linux、商用UNIX、Android、iOS等の端末やサーバのOS、ルーターやファイアーウォールのOS、Java、Apache、Oracle、WebLogic等のミドルウェアと呼ばれるソフト、WordPress等のソフト、SAP等のパッケージソフト、Word、Adobe Flash Player、Chrome等のアプリケーションソフトととにかくソフト全般に脆弱性があり、日々、新しい脆弱性が発見されている状況です。
ちなみに、小見出しの13792、これはJPCERT/CCとIPAが運用している脆弱性データベースであるJVN(Japan Vulnerability Notes)に2017年に登録された脆弱性の件数です。１年365日ですから、１日平均37.8件。セキュリティ担当者はこれらの脆弱性情報を脆弱性管理として運用していくわけです。
とはいえ、年間1万件以上あるとなると、効率よく処理していく必要があります。そのために、脆弱性情報を選別して処理していく必要があります。
選別の順序としては、
自組織に関係しているか？
予め対応の仕方が決まっているか？
パッチの適用等が必要なものか？
あたりになります。
構成管理はどんな形であっても必須
まず、「1. 自組織に関係しているか？」です。
当たり前ですが自分の組織で使っていないソフトの脆弱性情報は関係ない、ということです。ただ、自分の組織で使っているソフトウェア、ハードウェアをきちんと把握できていないと、どの脆弱性が関係するのかが判別できません。
そのため、システムの構成管理ができている必要があります。管理する情報としては、ソフトウェア名は勿論ですが、バージョンもメジャー・バージョンくらいを押さえておくとかなり便利です。
そして、ここで問題になるのは、「シャドーIT」と呼ばれたりしますが、組織内で把握できていないシステムがあると、それらの脆弱性情報を取り逃すことになるため、気を付ける必要があります。
「とりあえず、自動的にパッチを当てる」でも良いか？
次に、「2. 予め対応の仕方が決まっているか？」ですが、例えば、端末搭載のソフトウェアでパッチの自動更新機能があるもので、脆弱性に対するパッチが提供されているものについては、強制的に自動更新としておいてもいいかな？と個人的には思います。
そうなると、端末搭載のソフトウェアについての脆弱性については、「とにかく早く更新しろ」とするだけでよいため、それ以上の判断は不要となります。
もし、それで何かしらの不具合が出たなら、その時に考えても良いと思いますので・・・。
To be or not to be: that is the question.
さて、残るのは「3. パッチの適用等が必要なものか？」ということで、脆弱性情報を読み取って、対応を決める必要のあるものになります。
最終的には、脆弱性へのパッチを当てるべきか？もしくは、別の回避方法を行うか？それとも、放っておくか？を決めるわけになるのですが、そのために脆弱性情報の見方を覚えておくと便利になります。
ざっとした判断をするのであれば、以下の情報を見てフィルタリングするとよいかもしれません。
▪️ CVSS値
脆弱性の深刻さというか、それを利用した攻撃の発生のしやすさを10点満点で評価しています。ベンダーが自社の脆弱性を評価するときも、CVSS値で何点以上なら「緊急」、「重要」なら何点、と決めていたりします。この点数だけで決められるわけではないですが、何点以上であれば、詳細を見る、という形でもそこそこ有効です。
▪️ 脆弱性の概要
そのソフトのどの機能に脆弱性があるのか、また、その脆弱性を攻撃すると事故として何が起こるのか？が書かれています。
まず、脆弱性のある機能を自組織で使っているか？どうかで対応すべきかどうかの判断ができます。また、事故として何が起きるのか？ですが、例えば「攻撃による機能停止」「管理者権限の奪取」「任意のコードの実行」「権限昇格」「バッファオーバーフローの可能性」「認証機能の回避」のような表現で書かれています。それらの中で、「これ起こったら本当に大変」というものを選ぶのはありです。
▪️ 攻撃の場所
脆弱性を攻撃するのに、ネットワーク越しに攻撃できるのか(remote)、もしくは脆弱性のある端末・サーバ等にログインする必要があるのか(local)が書かれています。
一般に、ネットワーク越し(remote)のほうが危険です(CVSS値も高い)ので、優先的に見ていくといいかもしれません。
▪️ 攻撃のためのコード/実際の攻撃の確認
実際に、その脆弱性を狙った攻撃が確認されていたり、攻撃のためのコードが公開されていたりする場合があります。その場合には、優先して見るべきでしょう。これらの情報をベースに自組織のシステムと照らし合わせて、パッチを当てるのか、別の回避方法をとるのか、放っておくのか？を決めていく必要があります。
まずは、情報を収集することから・・・
さて、ともあれ脆弱性情報を収集しなくては始まらないのですが、「脆弱性」というと意味がよく分からないというか、実はいろんな意味で使われていたりする場合がありますし、一般的には使われない用語なので、無理に小難しい日本語にせずに、「セキュリティホール」と言った方がいいと思うんですけどね・・・。
この記事が気に入ったらサポートをしてみませんか？