Kali Linux in Action: [翻訳] 情報セキュリティ評価の基礎

ラファエル・ハーツォーグ(Raphaël Hertzog), ジム・オゴーマン(Jim O’Gorman), and マティ・アハロニ(Mati Aharoni)
(翻訳: Takayuki Kawamoto)

Chapter 11: “Introduction to Security Assessments” in Kali Linux Revealed: Mastering the Penetration Testing Distribution. Offsec Press, 2017, pp.279-298.
1st appeared at www.markupdancing.net as Japanese translation: 2018-02-19 13:59:51.
This usage of original document should follow the terms of Creative Commons Attribution-ShareAlike 3.0 Unported License (CC BY-SA 3.0.) and “Kali Linux” is a trademark of Offensive Security. Any use or distribution of this book, modified or not, must comply with the trademark policy defined here: https://www.kali.org/trademark-policy/. All Rights Not Explicitly Granted Above Are Reserved.

訳者の但し書き

本稿では、数字表記の注記「(1)」は原著の注釈を表し、それ以外の記号による注記「*」は訳者(河本)の注釈です。また、本文中に挿入している [...] も訳者の追記です。

Desktop on Kali Linux

ここまで、Kali Linux だけに関わる多くの機能を取り上げてきたので、あなたは Kali Linux の特徴をよく理解できたでしょうし、Kali Linux で複雑な仕事をどうやって成し遂げるかも理解できた筈です。

ですが、Kali Linux で仕事を始めるにあたり、情報セキュリティ評価に関わる幾つかの考え方を理解しておかなくてはなりません。そこで、この章では [本稿は書物の一章を翻訳しているため、著者たちはこのような表現をしています] 情報セキュリティ評価を始めるために必要なこれらの考え方を紹介して、情報セキュリティ評価に当たって Kali を使う必要が出てきたら助けになる筈の参考情報を与えます。

まず、情報システムを取り扱うに当たって「セキュリティ」とは正確に言って何のことなのかを見定めておくことが大切です。或る情報システムを「セキュア(安全)」とするためには、そのシステムについて三つの主要な属性に着目しましょう。

これらは一緒に CIA の三つ組を構成し、大多数の場合において、これらの三つ組はあなたが標準的な仕方で機器やサービスを配置したり保守運用したり評価する際に、或るシステムを安全にしようとするにあたって着目する主要な項目となっています。

それから重要なこととして、幾つかの状況においては、CIA の三つ組でどれか一つを他の二つよりも重視することがあるかもしれません。、あなた自身が秘密にしておきたい意見を書き留めたメモ帳があるとしましょう。すると、そのメモ帳の機密性は完全性や可用性に比べて、あなたにとって重要な関心事となりえます。言い換えると、誰かがそのメモ帳に何かを(読むのとは逆に)勝手に書き込めるかどうかとか、そのメモ帳をあなたがいつでも使えるかどうかは、誰かが勝手にあなたのメモ帳を手にできるかどうかという問題に比べたら、あなたにとって大した心配事ではないかもしれません。別の状況を考えると、もしあなたが医療カルテの履歴を管理するようなシステムを安全にするなら、データの完全性は最も重大な関心事となるでしょう。確かに、誰がどういう薬を使っているかという情報へ無関係な人がアクセスできないようにすることは重要ですし、必要に応じてあなたが情報のリストへいつでもアクセスできるようにすることも重要ですが、もしシステムが扱っている情報に誰かがアクセスして情報(すなわちシステムの完全性)を変えてしまうことができれば、それは人の生命を害するような結果に至るかもしれません。

あなたがシステムを安全にしようというときに問題を見つけたらなら、これら三つ組のうちでどれか一つの概念、あるいは幾つかの概念の組み合わせを念頭に置いて、問題がそれらのうちどれに関わっているのかを考えなくてはならないでしょう。そうすることで、あなたは更に包括的な仕方で問題を理解できるようになり、問題を整理して適切な対応を採れるようになります。そうして、脆弱性が CIA 三つ組の一つまたは複数の概念においてどう影響するかが分かるようになるかもしれません。ここで、SQL インジェクションという脆弱性を抱えているようなウェブアプリケーションを題材にしてみましょう。

CIA の三つ組の元になっている考え方は何もべらぼうに複雑なことではありませんし、普段の業務で自覚していなくても、誰もが直観的にそれらを念頭に置いて現実に仕事をしているような概念なのです。とは言え、これらの概念をよく自覚して扱えば、どういうことに自分の努力を向けたらよいのかがはっきりと分かるようになります。そして、これらの概念を使えば、システムの中で重大な部分を特定するための役に立つでしょうし、特定した問題をそれぞれ修正するために努力やリソースを費やすだけの価値があると分かるでしょう。

この他に詳しく説明しておきたい概念は、リスク と、リスクがどのように脅威脆弱性から構成できるのかということです。これらの概念も大して複雑ではありませんが、誤解され易い概念でもあります。これらについては後から詳しく扱いますが、大まかな説明をしておくと、リスクとはあなたが起きないようにしたいことであり、脅威とはそれを起こそうとする者であり、脆弱性とはそれをやらせてしまう状況のことだと理解すればよいでしょう。脅威や脆弱性に対しては、リスクを緩和するという目的の管理策を実施します*

*情報セキュリティ・マネジメントの用語としては、“controls” は「管理策」と訳す決まりになっています。「対策」でも意味は殆ど同じですが、「対」という語に通じる別の相手が存在するとは限らないので、厳密には「対策」は意味が狭い(あるいは余計な先入観を与える)ために、本稿では使いません。改めて書くまでもないと思いますが、著者たちは(そして訳者の僕もそうですが)情報セキュリティの専門家や実務家であって、Linux の技術者やプログラマというバックグラウンドだけでものを書いているわけではありません。彼らの使っている語句はまず情報セキュリティの専門家としての意味が優先されるべきでしょう。

ここで一つの事例を考えてみます。あなたがどこか他の国や地域を訪れるとき、あなたがマラリアに感染する高いリスクがあります。なぜなら、その場所には蚊がたくさんいるという大きな脅威があり、加えてあなたはほぼ確実にマラリアへの耐性がないからです。でも幸運なことに、あなたは薬で脆弱性をコントロールできますし、虫よけ剤や蚊帳で脅威をコントロールしてみることだってできるでしょう。脅威脆弱性の双方に管理策を適用すれば、そういう特定のリスクが顕在化しないよう確実に対処できるでしょう。

冒頭に戻る

11.1 Kali Linux を評価に使う*

*本稿は原著の第11章の翻訳なので、章立ては原著のままとした。

Kali LInux を実務で使う準備をしているなら、まず最初にあなたは Kali Linux を作業用にクリーンな状態でインストールしていなければなりません。セキュリティ実務の多くの初心者にありがちな間違いは、Kali Linux を一度だけインストールしておいて複数の評価をこなそうとすることです。これは、次のような主に二つの理由で問題があります。

これが、Kali Linux をクリーンな状態でインストールして評価を始めなくてはいけないと強く求められる理由であり、カスタマイズした Kali Linux を用意して自動化されたインストール手順を導入すれば上手く行くとされる理由でもあります。これを改めて確認するために、9.3 節(「カスタムの Kali Live ISO イメージを作成する」, p.236*)と 4.3 節(「固有値を指定したインストール」, p.91)を参照してください。その日にインストールを適正に自動化しておけば、翌日は無駄な時間がもっと減ることでしょう。

*ここでのページ番号は原著のもの。

Kali Linux を現場で使うためにどうやって調整しておくかということは、人によって色々な要件があります。しかし幾つかの普遍的な推奨事項があって、それは実際にあなたが従おうと思うようなことです。まず、4.2.2 節(「全体を暗号化したファイルシステムへのインストール」, p.85)で説明したような、暗号化したパーティションへのインストールを利用することを考慮してみてください。このインストール手法は、物理的な機器のデータを保護してくれて、もしあなたのラップトップ・コンピュータが盗まれた場合の救いになります。

また、移動しているときの安全策として、あなたは会社の同僚へ暗号化した復号化キーのコピーを送信した後で、データを全く復号化できなくしたいと思うかもしれません(「更に安全とするための自爆パスワードを追加する」, p.245)。このやり方を使うと、会社に戻って復号化キーでデータを復旧するまではデータを安全に守れます*

*この nuke password は、暗号化されているパーティションを復号化するための秘密鍵を全て消去してしまう「自爆用パスワード」です。通常は、ラップトップ・パソコンを拾ったり盗んだ人間が “01234” や “billgates” といった愚かなパスワード(ちなみに、Bill Gates が愚かだと言いたいわけではありません)を入力したときに自爆する(復号化するキーを全て消去するので、誰もデータを復旧できなくなる)ための機能ですが、あらかじめ復号化キーをバックアップしておいて、わざと自分で nuke password を入力すれば、移動のあいだにラップトップ・コンピュータが盗まれたり紛失しても、誰も復号できません。

その他に何度か確認し直すべきなのは、あなたがインストールしたパッケージの一覧です。自分の仕事を達成するために必要と思われるツールが何であるかを、まず考えなくてはなりません。、もしあなたが無線通信のセキュリティ評価を始めようとしているなら、あなたは kali-linux-wireless というメタパッケージをインストールしようと思うかもしれません。このメタパッケージは、Kali Linux で使える無線通信の評価ツールを全て含んでいるからです。あるいは、ウェブアプリケーションの評価をすることになったら、あなたは kali-linux-web というメタパッケージで使えるようになるテスト用のツールを全てインストールすることでしょう。セキュリティ評価をしているあいだは、あなたがインターネットへ簡単にアクセスできるとは限らないと想定しておくべきなので、あらかじめできることはやっておきたいと思うはずです。

同じ理由で、あなたはネットワークの設定を見直そうとするかもしれません(5.1 節「ネットワークの調整」, p.104 と 7.3 節「ネットワーク・サービスを安全にする」, p.153 を参照してください)。そこで、DHCP の設定を再確認したり、マシンに割り当てた IP アドレスで listen しているサービスを見直しましょう。それらの設定は、あなたの仕事に致命的な影響をもたらすかもしれません。立ち上がっているサービスが少なすぎてレスポンスを得られないマシンでは評価ができませんし、立ち上がっているサービスが多すぎるマシンはシステムを脆弱にするかもしれず、そのような状況だと評価を始める前にマシンを落した方がマシです。

もしあなたがネットワーク侵入の検査に関わっているなら、あなたのマシンのネットワーク設定をよく注意することが更に重要となりますし、攻撃されているシステムに何らかの変更を加えないようにしなくてはなりません。kali-linux-forensic というメタパッケージでカスタマイズされた Kali Linux をフォレンジックス・モードで起動すると、ディスクを自動でマウントしてはくれませんし、スワップ用のパーティションを自動で使ったりもしません。このやり方だと、あなたは Kali Linux で使えるフォレンジックス用の多くのツールを使っているあいだ、あなたのマシンの分析を受けているシステムの完全性を保ちながら作業できます。

重要なのは、仕事に使うマシンに Kali Linux をインストールする場合は、正しく準備しなくてはならないということです。Kali の環境をクリーンに、十分なセットアップで、効果的に準備できていれば、その後の全ての手順はいつでも滞りなく行くことでしょう。

冒頭に戻る

11.2 評価の種別

ここまでの手順で Kali Linux の環境をしっかり準備できたでしょうから、次は、あなたが正確にどういう評価をしたいのかを決めましょう。大きく分けると、それらの評価は四つの種別になります。つまり、脆弱性評価コンプライアンス検査従来通りのペネトレーション・テスト、そしてアプリケーション評価です。実務では、それぞれの種別の評価は色々な点で違っているかもしれませんが、それらの評価を幾らか詳しく説明して、Kali Linux を構築したり扱う環境にとって各評価がどういう関係にあるのかを説明することには、大切な意味があります。

これらの評価を詳しく調べてゆくにあたって、まず知っておくべきなのは、脆弱性とエクスプロイトの違いです。

脆弱性は、何らかの弱点とか欠陥だと定義でき、それを利用すれば情報システムの機密性、完全性、あるいは可用性を低減させられるものです。情報システムが抱えるかもしれない脆弱性には次のようなものがあります*

*以下の文章でも出てくるように、情報セキュリティ関連の専門用語は定訳がなかったり、“command execution” を「任意のコマンドを実行される(脆弱性)」などと説明的に翻訳している事例があります。なお、僕(訳者)は国内の事業者が使うような、末尾の長音を割愛する表記ルールには原則として従っていませんが、“user” を「ユーザ」と表記することはあります。

これらに対して、エクスプロイトというのはソフトウェアであり、それを使うと特定の脆弱性を攻撃できるものを指しています。とは言え、全ての脆弱性が何らかのエクスプロイトで攻撃可能であるとは限りません。エクスプロイトは現実に動作しているプロセスに何らかの変更を加えるものであり、プロセスに想定外の挙動をさせるので、エクスプロイトを作るのは非常に複雑となるかもしれません。更に、現代のコンピューティング基盤においてはエクスプロイトに対抗するテクノロジーが数多くあって、データ実行防止機能(DEP: Data Execution Prevention)やアドレス空間配置のランダム化(ASLR: Address Space Layout Randomization)のような技術で、脆弱性を攻撃するのは困難になっています。とは言いつつも、或る脆弱性について公に知られているエクスプロイトがないというだけで、エクスプロイトが全くない(あるいはエクスプロイトを作れない)とは言えません。、多くの組織は公になっていないエクスプロイトを販売しているので、どんな脆弱性であろうと、潜在的には何らかの仕方で実際に攻撃されうるのだと考えるべきでしょう。

冒頭に戻る

11.2.1 脆弱性評価

脆弱性は弱点であり、情報システムの機密性、完全性、あるいは可用性を損なうような何らかの仕方を可能にしてしまいます。脆弱性評価でのあなたの目標は、目的の環境に見つけた脆弱性のひとまとまりを作り出すことです。この、目的の環境という概念は重要です。あなたは確実にクライアントのネットワークで作業していなければならず、要求された目標を達成するために必要な範囲で作業しなくてはなりません。評価の範囲を越えて作業するとサービスに介入することとなりえるので、それはクライアントの信頼を損なったり、あなたや会社がクライアントから訴えられるという結果もありえます。

脆弱性の検査は他と比べて単純なので、ライアントが善管注意義務を果たしているという証拠の一部に使えるくらい標準的な基盤として成熟している環境によって、検査を完遂できることもあります。たいていの場合、Kali Tools のサイトや Kali デスクトップの Applications メニューにある、脆弱性分析(Vulnerability Analysis)それからウェブ・アプリケーション(Web Applications)というカテゴリにある自動化ツールは、目的の環境で実行中のシステムを発見し、通信を待ち受けているサービスを特定して、それらのサーバ・ソフトウェアとかバージョンとか開発プラットフォームなどの情報を可能な限り発見して集めるために使われます。

そうして集められた情報は、潜在的な問題や脆弱性として既に知られているシグネチャがあるかどうかを検査されます。それらのシグネチャは、既知の問題を惹き起こすことを意図するようなデータ点を組み合わせたものです。複数のデータ点が使われます。なぜなら、データ点を多く使えば、それだけ何の脆弱性に関わるかがはっきりするからです。そういうデータ点は非常にたくさんあって、全てを尽くしているわけではありませんが、次のようなものがあります。

これらの、あるいはもっと多くのデータ点によって、脆弱性スキャンの一部として或る特徴が作られます。そこでは予想どおり、多くのデータ点が合致すればするほど、そのシグネチャがどういう脆弱性であるかがはっきりしてきます。そこで何か該当するシグネチャがあったら、それは以下のような、それぞれ異なる結果のどれかかもしれません。

予想通り、手にしているシグネチャの正確さは、これらの結果のどれになるかをはっきりさせるために重要なのです。データをたくさん手にすればするほど、シグネチャにもとづく自動化されたスキャンは正確な結果をもたらしてくれる可能性が高くなります。そして、認証されたスキャンがよく普及している理由もここにあるわけです。

認証されたスキャンでは、スキャン用のソフトウェアは、目的とする環境から認証されるよう、あらかじめ与えられた資格情報を使います。こうすると、資格情報を使って認証されない状況でスキャンするよりも、目的とする環境が更に深いレベルで見えるようになります。認証されない通常のスキャンだと、あなたには、目的とする環境で動いていて応答に反応するようなサービスから返された情報しか、そのシステムや機能については分からないでしょう。実に多くの情報が集まるかもしれませんが、それらはやはりシステムから認証されている場合にあなたが集められるようなレベルの情報は含んでおらず、インストールされている全てのソフトウェアや、適用されている全てのパッチや、稼動している全てのプロセスなどを包括的に評価するには足りません。これらの範囲の情報は、他のやり方では見つけられなかったかもしれない脆弱性を見つけるために有益です。

適正に実施された脆弱性評価は、その組織が評価した時点で潜在的に抱えている問題を描き出してくれたり、時系列に沿ってどのような変化が起きるかという指標を与えてくれます。これは、やや簡単な評価ですが、それでも多くの組織では規則的に自動化された脆弱性スキャンを営業時間外に実行しており、サービスの可用性や帯域が最も重要である日中に潜在的な問題が表に出てこないようにしています。

先に述べたように、脆弱性スキャンは多くの異なるデータ点を点検して正確な結果を得なくてはなりません。それらの異なるデータ点を全て点検することにより、目的とするシステムで負荷を発生させたり帯域を消費することがありえます。あいにく、目的とする環境がどれだけの数のサービスを使ったり、それらのサービスに関わる点検の種類が増えると、結果としてリソースをどれくらい使うのかは、正確には分かりません。これはスキャンする場合のコストというものであって、システムのリソースは必ず消費されるのです。これらのツールを使うなら、リソースの消費について一般論を知っておき、目的とするシステムならどれくらいの負荷がかかるかを予想するのは重要です。

スキャンのスレッド
多くの脆弱性スキャナは、「スキャンごとのスレッド数」という設定項目を持っていて、これは一度に検査できる数と同じことです。この数を増やしていくと、目的の環境に与える負荷だけでなく、スキャナを動かしている方の環境やネットワークにも負荷がかかり、直接の影響が出てくるでしょう。このようなスキャナを使う場合には、このことに留意しておくのが大切です。スキャンを早く終わらせたいと思うあまりスレッド数を増やしてしまうのは人情というものですが、数字が単に増えるだけではなく環境への負荷も上がるのだということを忘れないようにしてください。

脆弱性のスキャンが完了したら、そこで見つかった問題は CVE 番号や EDB-ID あるいはベンダーが公表しているアドバイザリのような、業界内で標準化された識別子にリンクされていることがよくあります。これらの情報は CVSS 脆弱性評価指標の値を伴っていて、個々の問題のリスクを見積もるために使います。偽陰性(それから偽陽性)の可能性を考慮すると、これらの情報を使ったリスクの見積もりには、スキャンの結果を解析するときに考慮すべき共通の問題があります。

自動化されたツールは脆弱性を発見するためにシグネチャのデータベースを利用するので、スキャンされたデータが既知のシグネチャと少しでも違えば結果は違うものとなり、それゆえ脆弱性の見かけの判定内容も違ってきます。その判定に偽陽性があれば、本当は存在しない脆弱性が存在するかのように間違って印を付けてしまうことになりますし、偽陰性があれば、存在している筈の脆弱性を実際には隠してしまうことになります。よって、脆弱性スキャナはシグネチャのルールにもとづく限りで正しいだけだと言われるのです。このような理由から、多くのベンダーではシグネチャの複数のセットを提供していて、一つは家庭用として自由に使えるセット、そしてもう一つはかなり高価なセットであり、たいていは企業向けに販売される、更に包括的なシグネチャのセットとなっています。

その他、脆弱性スキャンには提示されたリスクの見積もりが妥当なのかどうかという問題があります。リスクの見積もりは、権限のレベル、ソフトウェアの種別、それから認証の前なのか認証された後なのかといった、多くの異なる要因を考慮した概括的な条件によって定義されています。あなたの環境によっては、このような見積もりの条件が当てはまらないかもしれないので、見積もりをむやみに受け入れてはなりません。脆弱性評価に精通している人々だけが、リスクの見積もりが本当に妥当であるかどうかを正しく判定できるのです。

リスクの見積もりについて誰もが認めるような決まった合意など存在していませんが、NIST の Special publication である 800-30 番の文書は、あなたの環境でリスクの見積もりが妥当と言えるかどうか、そして正確にリスクを見積もっているかどうかを評価するための基礎として推奨できます。NIST SP 800-30 は、見つけた脆弱性の本当のリスクというものを、それが顕在化する可能性と潜在的な影響度の組み合わせとして定義しています。

リスクが顕在化する可能性

アメリカ国立標準技術研究所(NIST: the National Institute of Standards and Technology)によると、何かが顕在化する可能性とは、或る特定の脅威が或る特定の脆弱性を利用できる確率にもとづいて、次のような低、中、上という段階で区別された見積りのことです。

影響度

影響度のレベルは、問題にしている脆弱性が利用されたり悪用されたときに生じる被害の量を見積もって決まります。

総合としてのリスク

リスクが顕在化する可能性と影響度が決まれば、そこからあなたはリスクの総合的な評価を、それら二つの見積もりから得る関数として決められます。総合的なリスクは低、中、高として見積もられて、問題になっているシステムを安全にしたり運用する責任者へ、それぞれの見積もりに応じて以下のような助言を与えます。

要約

見つかった脆弱性の本当のリスクというものは非常に多くの要素を含んでいるので、ツールの出力結果から決まるリスクの評価というものは、組織全体に及ぶ本当のリスクを決めるための出発点でしかありません。

脆弱性評価による立派な報告書は、専門家によって分析された結果であれば、コンプライアンスのためのペネトレーション・テストといった他の評価を始めるにあたっての基礎となりえます。したがって、最初の評価で可能な限り最善の結果を得るために、何が求められるかを理解しておくことは重要なのです。

Kali は脆弱性評価を実行する優れたプラットフォームを提供し、特別な調整は必要ありません。Kali Applications のメニューには、“Information Gathering”、“Vulnerability Analysis”、そして “Web Application Analysis” というカテゴリーに、脆弱性評価で使う数多くのツールがあります。それから先に言及したとおり、Kali Linux Tools Listing、Kali Linux の公式ドキュメント、それからフリーの Metasploit Unleashed オンライン・コースなどを含む幾つかのウェブサイトは、Kali Linux で脆弱性評価を実施するにあたって優れたリソースを提供しています。

冒頭に戻る

11.2.2 コンプライアンスのためのペネトレーション・テスト

複雑さに応じた別の評価方法として、コンプライアンスに準拠したペネトレーション・テストというものがあります。これは、最も標準的なペネトレーション・テストであり、政府や産業界で要求され、それらの組織が全体で従うコンプライアンスの枠組みに準拠したテストです。

産業別に応じて様々なコンプライアンスの枠組みがあるとはいえ、最も普及しているのは、恐らくペイメントカード業界データセキュリティ基準(PCI DSS: Payment Card Industry Data Security Standard)でしょう*。これは、カード会社によって求められている枠組みであり、小売り業者がカードで決済処理を扱うときに従わなくてはならないものです。とは言え、他にも数多くの規格があり、たとえば米国国防情報システム局のセキュリティ技術実装ガイド(DISA STIG)、米国連邦政府のリスク・認証管理プログラム(FedRAMP)、連邦情報セキュリティマネジメント法(FISMA)などがあります。場合によっては、クライアント企業は評価を求めるかもしれませんし、色々な理由で直近の評価の結果を見たがるかもしれません。そして、それが場当たり的な理由であれ、あるいは所定の求めに応じるためであれ、これらの評価はまとめてコンプライアンスのためのペネトレーション・テストと呼ばれたり、あるいは単に「コンプライアンス評価」とか「コンプライアンス・チェック」などと呼ばれたりもします。

*定訳がなく、「PCIデータセキュリティスタンダード」と表記されることもあるが、そもそも名前が長いので、国内でも「PCI DSS」と表記している場合が多い。

コンプライアンスの確認は、しばしば脆弱性評価から始まります。PCI コンプライアンス監査においては、脆弱性評価を適正に実施すれば、基本的な幾つかの要求事項を満たしていることになります。そういう要求事項には、「2. システムのパスワードやセキュリティ設定として、ベンダーから支給されたものをそのまま使ってはいけない」(たとえば、Password Attacks メニューのカテゴリから使えるツールを使って検証します)とか、「11. セキュリティ・システムや処理手順を定期的に確認せよ」(Database Assessment カテゴリのツールを使って検証します)という事項があります。「9. カード所有者のデータへの物理的なアクセスを制限せよ」とか「12. 全ての従業員にかかわる情報セキュリティのポリシーを整備せよ」といった要求事項は、従来のツールを使う脆弱性評価には適していないように思えるので、更に違った発想や検証方法が求められます。

Kali Linux をこれらのコンプライアンスの確認に使うというのは、やや乱暴な説明のように思えますが、それはそれとして Kali Linux がこういう環境に最適なのは、何も Kali Linux がセキュリティに関する幅広いジャンルのツールをサポートしているからというだけではありません。Kali Linux がオープンソースの Debian の環境として作られていて、幅広いジャンルのツールをインストールできるからでもあります。あなたが利用するコンプライアンスのフレームワークで使われているキーワードを注意深く選んでパッケージ・マネージャを検索すれば、ほぼ確実にキーワードへ対応するパッケージが幾つか見つかることでしょう。このようにして、多くの組織では Kali Linux をこれら全ての評価において使える標準的なプラットフォームとして採用しているのです。

冒頭に戻る

11.2.3 従来のペネトレーション・テスト

従来のペネトレーション・テストというものを定義するのは難しくなってきています。なぜなら、異なる定義から多くの実務が既に行われていて、そういう定義は現実に行われている実務へ逆に依存しているからです。こうした異なる定義が飛び交う混乱した状況は、「ペネトレーション・テスト」という言葉を、先のコンプライアンスのためのペネトレーション・テストという意味で(あるいは脆弱性評価という意味ですら)使うことが多くなってきたことにも原因があります。そういう状況においては、あなたは最低限度の必要を越えて、わざわざ評価について詳しく調べたりはしないのです。

この節の目的を考慮すると、組織全体のセキュリティを実際に改善するようなものという必要最低限度で理解した、情報セキュリティ評価というものの意味合いを越える議論にまで及ぶのは避けたいところです。

先に述べたタイプの情報セキュリティ評価とは反対ですが、多くのペネトレーション・テストでは評価する範囲を定義して始めたりはせずに、「組織内のユーザが情報を漏洩していた場合に何が起きるかをシミュレートする」とか、「組織が外部の危険人物から攻撃対象にされたらどうなるかを特定する」といった目標を決めて始めます。この手の評価が他と違っているのは、ペネトレーション・テストは脆弱性を単に見つけて妥当性を見積もるだけではなく、見つけた問題から最悪の場合にどうなるかを明らかにすることにあります。この評価では、脆弱性スキャナという重厚なツールに評価の手順を完全に依存するのではなく、あなたはエクスプロイトを試したり、偽陽性を取り除くためにテストしたり、あるいはベストと尽くして隠れた脆弱性もしくは偽陰性を見つけたりして、得た結果を妥当なものにして評価を終えなくてはなりません。

[未完]

冒頭に戻る


※ 以下の SNS 共有ボタンは JavaScript を使っておらず、ボタンを押すまでは SNS サイトと全く通信しません。

Google+ Twitter Facebook