サイバー攻撃の激化に伴い、脆弱性診断の重要性が増している。システムやソフトウェアの脆弱性を開発時点で完全に解消することは困難であり、攻撃者はその隙を狙っている。この記事では、脆弱性を見つけ出すために有効とされる脆弱性診断について、ペネトレーションテストとの違いに触れながら解説する。
脆弱性が生じる理由
脆弱性とは、システムやソフトウェアに潜む情報セキュリティ上の欠陥のことだ。セキュリティホールと同義と捉える向きもあるが、厳密には両者の意味は異なる。セキュリティホールがソフトウェアの欠陥（バグ）のことなのに対し、脆弱性は欠陥の範囲に仕組みや運用面なども含めた、外部からの攻撃に対する弱点という意味だ。
攻撃者は脆弱性を見つけ出して悪用し、不正アクセスやマルウェアを用いて攻撃を行う。脆弱性が存在する状態でシステムやソフトウェアを運用することは極めてリスクが高いものの、一方でシステムや運用上において完全に脆弱性を排除するのは極めて難しい。一般的に、脆弱性は以下のような原因で発生する。
１）開発段階での設計ミスやテスト不足
ソフトウェアの開発者は、脆弱性を生じさせないように丁寧な設計を行い、開発段階では逐次検証を行いながら、脆弱性を解消していく。しかし、既知の攻撃方法であっても、そのすべてに対応することは容易ではなく、ましてや開発時点で未知の攻撃手法へ対応することは不可能に近い。攻撃されて初めて、脆弱性に気づき、狙われた脆弱性への対処が可能となるのが実際のところだ。そのため、「可能な範囲」で脆弱性の解消に手を尽くすというのが現実的な対策となる。
２）システム構築における連携の複雑さ
システム構築においては、ネットワークやハードウェア、ミドルウェア、アプリケーションが複雑に連携する。ソフトウェア単体ですら脆弱性の完全な解消は難しいにもかかわらず、より広範囲となれば脆弱性は予期せぬところで生じ得るものだ。連携対象が広がるほど、必要な検証項目が乗算的に増えることになってしまう。３）サプライチェーン攻撃
近年、オープンソースの利用が一般化したことで、ライブラリー、コンポーネントと呼ばれる、ソースコードのパーツのようなものの利用も広がっている。また、コンポーネントの中に埋め込まれるコンポーネントといったように、利用する開発者もその存在を認識することなく用いている場合もある。こうした開発プロセスで利用されるコンポーネントに脆弱性が生じる場合がある。加えて、バックドアやマルウェアを埋め込まれるといったことも実際に起こっている。2021年にはデバイスのアクティビティログを記録するために利用される、Log4jと呼ばれるソフトウェアのライブラリーにて発覚した脆弱性「Log4Shell」を狙う攻撃が発生。この手の問題が深刻であることを世界に知らしめた。
脆弱性診断とは
開発段階において脆弱性を完全に排除しておくことは不可能に近い。しかし、脆弱性を解消しなければ、先述のようにさまざまなリスクに直面するのが実情だ。そのため、システムの開発・運用時に脆弱性診断を行うケースが増えている。
脆弱性診断は、基本的にOSやミドルウェア、ネットワークといった個所ごとに、脆弱性を顕在化するための検査として、チェックリスト型にて診断を行う。検査をしたい個所に応じた検査項目を決定し、網羅的に診断を行っていくことになる。脆弱性診断の実施には、プログラムやアプリケーションに対する知識に加え、ツールの活用に関する見識も問われる。高い専門性が求められるため、脆弱性診断を外部委託する企業も少なくない。
脆弱性診断とペネトレーションテストとの違い
ソフトウェアやシステムに潜む脆弱性を顕在化する手法として、ペネトレーションテストもよく知られている。この両者にはどのような点で違いがあるのだろうか。
ペネトレーションテストは日本語で「侵入テスト」と表現される。この文字面のとおり、ソフトウェア、システムに対して実際に侵入を試みるテストを行う。テストにあたっては、さまざまな攻撃手法を駆使して侵入の可能性を探り、システムの安全性を確かめる。侵入を試みる技術者は高度で専門的な知識・スキルが求められ、ホワイトハッカーとも呼ばれる。
ペネトレーションテストの場合は、システム全体が対象で、トライアンドエラー型のテストを行うことになる。一方で、脆弱性診断ではOSやネットワークといった個所ごとにチェックリスト型の診断を行う。端的に言えば全体最適を目指すのか個別最適を目指すのかという方向性が異なる。
ソフトウェアやシステムの脆弱性を解消するために、脆弱性診断とペネトレーションテストのどちらか一方を行えばよいというわけではない。脆弱性診断で個別に脆弱性が解消している場合であっても、システムが複雑に連携していることで予期せぬ脆弱性が生じている可能性もある。また、パスワードや権限管理などに関する不適切な運用が脆弱性になり得る場合もある。
ペネトレーションテストの結果、侵入の糸口を発見できなかった場合でも、システム上の軽微な脆弱性が脆弱性診断で発見できる場合もある。ソフトウェア開発やシステム構築の段階では、完全な脆弱性の解消を期待するのは現実的ではない。そのため、脆弱性診断とペネトレーションテストそれぞれに取り組み、潜在的な脆弱性の可視化・解消を継続的に検証しながら目指していくことが重要なのだ。
脆弱性診断は自社で行うべきか
脆弱性診断は、先述のように高度な知識と適切なツールの利用が求められる。そのため、外部のセキュリティ専門企業にアウトソースすることも少なくないが、脆弱性診断に用いるツールも普及しており、自社で行うことも不可能ではない。
以下に、自社で脆弱性診断を行う場合とアウトソースする場合について、それぞれのメリットとデメリットを説明する。
１）脆弱性診断を自社で行う場合
自社で脆弱性診断を行う場合、IPAなどが公開している診断項目を1つずつ確認していくことでも実施が可能だ。すべての診断項目に人手をかけた作業で個別対応していくことになるため、人的リソースが多く求められる。そこで、診断する対象ごとに適切なツールを選択し、診断を自動化することで効率化を図ることも検討したい。
診断を自社で行うと、診断の対象範囲設定やスケジューリングの自由度が高く、コスト負担も抑えられる。一方で、自社に専門的な知識・スキルを有する従業員がいない場合、高度な知識に基づく診断が難しいことから、脆弱性を見過ごし、放置されかねないというデメリットもある。
２）脆弱性診断をアウトソースする場合
セキュリティ専門企業に依頼する場合、豊富な経験に基づいて脆弱性診断が行われる。高度な知識・スキルを有する技術者が最適なツールを選択し、精度の高い診断が期待できる。
診断結果に基づくレポーティングや対処方法に関するサポートも充実していることが多く、ソフトウェア、システムの脆弱性が生じている個所に対して、具体的な対応も取りやすい。診断結果を踏まえ、効率的にセキュリティ対策を講じられるものの、一定のコストが生じることに加え、自社に診断ノウハウが蓄積されないというデメリットもある。また、脆弱性診断を行う対象範囲を明確にしておかないと、アウトソース先とのトラブルの要因になることも考慮に入れておくとよいだろう。
自社で診断を実施する場合でもそうでない場合でも、それぞれにメリットとデメリットはある。どちらを選択すべきかは、当然ながら各社の置かれた状況やその目的によって異なってくる。選択する際には、脆弱性が悪用された場合の影響を事前に想定・推定しておくのが望ましい。
脆弱性を突かれ、個人情報などの機密情報が流出してしまったらサービスは致命傷を負いかねない。最悪の場合、サービスを強制的に終了させるようなケースも考えられ、過去に国内でも実際に起こっている。不測の事態が生じた際の代償は小さくないということを肝に銘じて選択するようにしたい。
