アプリケーションの公開とは、ある意味混沌としたインターネットの大海に漕ぎ出すようなものです。
船たるアプリケーションに脆弱性があると。。。
※画像はイメージです(from ヴィンランド・サガ)
船に欠陥があれば何かの拍子に浸水したり海賊に乗っ取られたりするように、アプリケーションに脆弱性があればまったく同様の事態が発生します。そのため、アプリケーションの公開、また公開中には脆弱性がないかどうかをきちんとチェックする必要があります。これがセキュリティ監査です。
システムのセキュリティ監査は、一般的にはアプリケーション部分に対するもの、インフラ部分に対するものの大きく2つに分けられます。
- アプリケーション監査
- SQLインジェクションやCSRFなど、アプリケーションの作りに起因する脆弱性の調査
- インフラ監査
- OSやサーバーなど、アプリケーションが乗るインフラについての脆弱性の調査
今回は、このうちインフラ監査についてその基礎的な手順をご紹介します。
ただ、特にアプリケーション監査はそうですが、セキュリティ監査は経験と勘に依存するところが非常に多いです。ここでご紹介するのは基本の型のようなもので、十分な監査を行うにはここから実戦経験を積んでいく必要がある点に注意してください(私自身もまた新米監査士です)。
脆弱性診断の手順
脆弱性診断の手順は、次の3ステップになります。
- 存在する脆弱性の洗い出し
- 発見した脆弱性に対するリスク評価
- 上記2点に基づく、適切な対策の提案
診断を行う際は相手側の環境が明かされている場合とそうでない場合があります。いわゆるホワイトボックス/ブラックボックステストです。私個人は今までホワイトで行ったことはないですが、アプリケーション監査を受ける際はソースコードを提出したこともあります。何れになるかはその時々と思います。
以下では、各ステップの詳細についてみていきたいと思います。
脆弱性の洗い出し
脆弱性の洗い出しに際して重要なのは、対象の環境を把握することです。とくに使用されている製品名とバージョンが重要な手掛かりになります。というのも、これらが分かればベンダなどから報告されている脆弱性について調べることができるためです。
洗い出しを行う際にはまずツールを使いますが、以後はその結果から不足している情報について仮説を立て、手動で確認していくことになります。
診断用ツール
診断には主に以下2つのツールを使います。下記以外にもツールはいろいろありますが、それぞれ検知できたりできなかったりがあるため、何れにしても最低2つ以上でチェックをした方が良いです。
- Nmap
- ポートスキャンに利用できるツールです。これで、対象サーバーのどのポートでどのサービスが動いているのかを把握します
- オプションについては、こちらのサイトによくまとまっているので、ご参考
- Nessus
- 脆弱性の検知を行ってくれるツール。出してくれるレポートが秀逸なので、基本はこの結果をベースにする。なお、利用時には必ずプラグインのアップデートを行う。
- Nessus Homeという個人利用版があり、こちらは無料で使える。
この他、手動で確認を行う際は加工したパケット/リクエストなどを送ることが多いので、HTTPプロキシなどがあると便利です。個人的にはFiddlerをよく使っています。
脆弱性情報の調査
各ツールの診断結果を突き合わせて照合作業を行い、手動確認も含めつつ製品/バージョンの特定ができたら以下のサイトなどを参考に、脆弱性情報を調べていきます。
- Security Focus
- 既知のセキュリティホールをベンダや製品名、CVE番号(発見された脆弱性につけられる番号)等で検索可能。
- CVE Details
- 脆弱性情報がダッシュボードのようにまとまっており、非常に見やすい
- Common Vulnerabilities and Exposures(CVE)
- 発見された脆弱性にたいして番号を振っているサイト。
- National Vulnerability Database
- CVEで採番された情報の詳細を記しているサイト。独自でCVSSというリスクの採点を行っており、リスク判定を行う際は参考となる。
- Japan Vulnerability Notes
- JPCERTとIPAが共同で運用しているセキュリティホールのデータベース。時々目当ての情報を得られないケースもあるが、日本語で記載されているので読みやすい。
また、製品のサポート期限が終わっていないかなどもチェックします。
こうして、脆弱性情報の洗い出しを行っていきます。
リスク評価
リスクの評価は、端的には脆弱性の影響の大きさと発現確率によって行います。以下では、High/Middle/Lowの3種類に分類を行った例です。
この区分けは診断士や状況などによって変わってきます。影響度が大きければすべからくHighにすべき、いや発現条件が難しければMiddleで、逆に影響度が中程度でも発現しやすければ・・・などなどです。
脆弱性の影響度の大きさは、National Vulnerability Databaseで公開されているCVSSスコアなどを参考にします。大抵BufferOverflowやStackOverflowなど、サーバーが攻略されてしまうような脆弱性はスコアが高めになっています。
発現のしやすさは、その脆弱性を再現・利用するのがどれくらい簡単かという点で評価します。特に、Exploit Codeと呼ばれる脆弱性をつくコードが公開されていたり、すでにマルウェアが出回っているようなものは発現確率が高いと評価します。
こうした指標を加味し、リスク評価を行っていきます。
対策の提案
最後に、リスク評価を基に対策の提案を行います。究極的には「すべて最新版に更新せよ」で話が終わってしまうのですが、稼働中のサービスだとそうはいかないので、優先的に対応すべきものをまとめて報告します。この際には、個人情報を扱っているか否かなど、サーバーの素性なども加味されると思います(ブラックボックステストの場合だと知る由がないところもありますが)。
以上が、インフラ監査の手順となります。