第22回 脆弱性検査
脆弱性検査は脆弱性の検査をすることだ。...すみません。
ブラックボックス検査とホワイトボックス検査の二種類がある。
ブラックボックス検査とは、相手の状態を知らずに検査するもの。
なので、一般的な検査(攻撃)を繰り出して突破できるかどうかを検査するもの。
ホワイトボックスは言葉自体が変だが(白くても中身が見えないのは一緒だ)、
ブラックボックスの反対の意味を指す。
つまり、相手の状態が分かった状態での検査となる。
この本では机上のと書いてあるが、机上とは限らない。
ちなみに、ブラックボックス・ホワイトボックスはプログラマーも使います。
システム(プログラム)のテストの方法として。
通常行っているのは、仕様に基づくテストなのでホワイトボックステスト。
第三者がいじわるなテストをするのがブラックボックステスト。
さて。ここでは、第三者が行う(とはかぎらんが)ブラックボックス検査を扱う。
でも、先入観なく検査するには第三者(外部業者)に頼むのがよいと思うけど。
通常はクラッカーもよく使うツール(方法論)で自動的にやる。
穴の確認だから別に人手はいらんのです。
ここでは、Webアプリケーションもその対象となっとる。
これはさっき書いたふつーのシステム(プログラム)のテストと同じことだ。
...って、この本の先回りをしたらしい。私。
これはシステムによって、インターフェースが違うので自動化は難しい。
もちろん、よくある穴(セッション管理、XSSなど)のチェックが目的なのは同じだ。
脆弱性検査も、毎回その内容や程度が違っていては意味がない...とまではいわんが、
同じレベルか前回以上(新しいセキュリティホールは続々と出るし、過去のはなくならないので。)の検査が必要。
それには、具体的にどんなテストを行うのか、規定しておく必要がある。
そうでないと、担当者(のレベルと意識)によって毎回検査の内容が変わってしまう。
検査とは、要はデバッグです。
ネットワークもシステムも新たなセキュリティホールが見つかるので、継続的な検査が必要。
通常のシステムは性善説に立って作られるので、機能が整っていれば十分だ。
けれども、外へさらすシステムは、機能が整っていると同時に、
セキュリティ的にも常に安全(セキュア)な状態が保たれていなければならない。
面倒な話だの。けれども、これが人間の本質だし、変えることなどできない。
常に起こりつつある、危機への対応がセキュリティ担当者の仕事。
...地味だの。いわゆる運用担当者ってやつだ。
