ITセキュリティテスト業務の紹介
概要
本記事ではセキュリティテスト業務の紹介を行う。
ITセキュリティは非常に幅広い業務であり、IPAでも様々な仕事が定義されている。
この分類を本記事内で全て紹介することはできないため、ここではITセキュリティの中でもテスト系の業務について紹介させていただく。
多くのセキュリティテストは特定の目的を、対象のシステム・機器に対して実施する。本記事ではその目的と対象についてそれぞれ解説する。
目的：脆弱性診断とペネトレーションテスト
セキュリティテストには大きく分けて脆弱性診断とペネトレーションテスト(以下、ペネトレ)がある。しかし、この２つの区別は難しく、セキュリティベンダーですら曖昧に運用しているという実情がある。
この２種は目的によって区別される。それは「脆弱性診断は脆弱性を全て列挙するためのもの」、「ペネトレは侵入可能性を検証するもの」である。
脆弱性診断
脆弱性診断は対象の脆弱性を全て見つけることを目的としている。例えばあるサーバに対して脆弱性診断を適用したとき、検査方法を定義し、その検査方法で見つかるサーバの全ての脆弱性を列挙することが目的になる。
ペネトレーションテスト
ペネトレーションテストは対象に侵入できるかを検証することが目的となる。脆弱性診断とは異なり脆弱性を見つけることが目的ではない。もちろん本サービスの中には脆弱性を調査する工程もあるが、それは侵入するための足掛かりとしての調査であり、仮に侵入に繋がらない脆弱性が発見されても報告しないことが多い。あくまで侵入に活用できた脆弱性のみが報告される。
このように説明すると脆弱性診断の方がセキュリティテストとして優れているように感じるが、ペネトレでは脆弱性を利用しない侵入も調査する。例えば「ユーザの認証情報を用いて不正にログインする」「公開を意図していないアプリを不正に操作する」等である。正常に認証することや、公開されたアプリを利用することは脆弱性とはいえないため脆弱性診断では報告されない。
このようにあらゆる手段を用いて侵入可能かを調査するのがペネトレである。
サービスの使い分け
脆弱性診断とペネトレはどちらがいいサービスであるということはなく、その目的によって使い分けるものである。
ただ、脆弱性診断の方が値段が安く需要が多い。何に対して脆弱性診断を実施するかにもよるが、比較的簡単に実施できるからだ。
ペネトレは実施に様々な準備が必要になることから手間が多く、値段も高い。脆弱性診断は1日~1週間ほどで終わることが多いが、ペネトレはサービスによっては１か月以上かける場合がある。
また、脆弱性診断は多くのベンダーでやり方や観点が共通していることに対して、ペネトレは「どのように実施するか」がベンダーによって大きく異なる。実際の攻撃者同様の動きをする本格的で高額なペネトレもあれば、簡易的に2,3日で実施できるペネトレもある。そのためペネトレをベンダーに発注する時はその中身を考慮したうえで、自社の目的に沿ったペネトレを選ぶ必要がある。
対象：何に対してテストするか
本章では脆弱性診断・ペネトレを何に適用するかについて記載する。
サーバ
特定のIPまたはドメインに対してテストを実施する。
具体的に言うなら、そのサーバ内で実行される各種サービスに対して脆弱性がないかを調査する。
脆弱性診断では主に「脆弱性が存在する古いサービスが動いていないか」が報告内容の中心になる。
ペネトレでは「脆弱性を利用できないか」「認証が突破できないか」「動いてるサービスを悪用できないか」等が報告内容になる。また、ペネトレの場合は単一のサーバだけでなく、ネットワーク全体のサーバを利用して特定のサーバに侵入可能かを調査する場合がある。
脆弱性診断の場合は診断ツールを適用するだけで完了する場合が多く、安価に大量に実施でき、また専門家がいなくても自社社員でも実施できることが特徴でもある。ただし、ツールを適用するのは簡単だが、そのレポートを正しく読み解くにはやはり専門家が必要になることが多い。
サーバに対する攻撃事例は枚挙にいとまがない。世の中の攻撃事例の多くが定期的なテストを実施すれば防げたものが多いため、本サービスはサーバを公開する場合は（可能なら社内のサーバに対しても）是非実施してほしい。
Webアプリ
ブラウザで動作するWebアプリケーションに対してテストを実施する。
ほとんどの場合が脆弱性診断であり、主にIPAやOWASPが提示するテスト要件に従ってテストを実施する。
https://www.ipa.go.jp/security/vuln/websecurity/ug65p900000196e2-att/000017319.pdf
こちらはサーバに対する脆弱性診断と異なり、専門家によるテストが推奨される。理由としては自動診断ツールでは発見できない脆弱性が複数存在するからだ。そのため専門家が各脆弱性を手動で確認する作業が必須になる。
ただし、安いベンダーに頼むと自動脆弱性診断ツールを適用するだけという場合もある。その場合は当然見つからない脆弱性がWebアプリに残存するため、ベンダーに頼む際は必ずテスト観点を確認してほしい。
Webアプリへの攻撃も非常によくニュースになる対象である。つい最近もWebアプリへの攻撃で30万人の情報が流出した。
https://xtech.nikkei.com/atcl/nxt/news/24/00849/
Webアプリを開発した際、または機能を追加した際は必ずこれらテストを実施することを開発スキームに組み込むべきである。
スマホアプリ・クライアントアプリ
スマホやPCで動作するアプリに対してテストを実施する。
これらはかなり専門性が高く、対応するベンダーが少ないという特徴がある。
テスト観点はベンダーによって色々あるが、OWASPのOWASP Mobile Application Securityが１つの基準になるだろう。
https://owasp.org/www-project-mobile-app-security/
疑似的な攻撃やアプリの解析、開発規約のチェックなどの様々な観点でテストを実施するが、サーバやWebアプリほどテスト方法が整理されてない(公開されていない)。
スマホ・クライアントアプリへの攻撃事例はサーバと比較すると小さい。それは攻撃そのもののコストが大きいからだ。ただし、それでも開発する場合は必ず実施するべきテストとなる。
Wi-Fiアクセスポイント
Wi-Fiのアクセスポイントに対してテストを実施する。
弱い暗号を使用していないか、リスクのある認証方式ではないか、管理者画面にアクセスできるか、意図しないアクセスポイントはないか等の観点を調査する。
総務省の出しているガイドラインを中心に検査するテストだと思ってもらえればわかりやすい。
https://www.soumu.go.jp/main_sosiki/cybersecurity/wi-fi/
Wi-Fiは意外にも攻撃者から狙われやすい。
そのアクセスポイントが利用できれば、そのネットワーク内全員の端末と通信可能になるし、管理者画面に入れれば罠サイトに誘導することも可能だからだ。
警察も警告をだしているくらいなので、もし自社のネットワークに不安があるならサービスを受けてみてもいいかもしれない。
https://www.keishicho.metro.tokyo.lg.jp/kurashi/cyber/notes/router.html
ICT機器
様々なICT機器(Webカメラ、エアコン、冷蔵庫、車…etc)に対してテストを行う。
スマホ・クライアントアプリ以上に専門的な領域であり、専門家が少ない。主に組み込みの知識や独自プロトコルの世界になってくるため、技術の習得難易度が高いからだ。そもそも日本語の本がほとんどない。
ただし、ICT機器の開発が増えていることから需要自体はそれなりにある。
またICT機器を狙った攻撃は右肩上がりに増えている。
このICT機器の増加と、専門家の不足は全世界の問題でもある。
ソースコード
主にWebアプリのソースコードに対してテストを行う。
Webアプリの脆弱性診断が完成したアプリにテストを行うものだったものに対して、こちらはソースコードに解析を行う。
観点が異なるためWebアプリ診断では見つからない脆弱性が発見されることが最大のメリットである（逆もまた然り）。
バッファーオーバーフロー、レースコンディション、ハードコーディングされた機密情報などは、基本的にはソースコード診断でしか見つからない。
正直需要はあまりないが、実施するとWebアプリ診断では見つからなかった「危ない」脆弱性が見つかることがある。そのため、自社のWebアプリの品質をより高くしたい人にはお勧めである。
ただし、大抵のベンダーにこのテストを頼むと診断ツールをかけて終わりという場合が多い。診断ツールは優秀だが非常に誤検出が多いという問題がある(つまり、脆弱性対応のコストが馬鹿みたいに高くなる)。一部のベンダーは検証までやってくれるが、お値段はそれなりになる。
余談だが、筆者の専門はこのソースコードの解析である。
まとめ
本記事ではセキュリティテストの業務の中でも代表的なものを紹介した。
セキュリティテストは明確な目的をもって、その目的にあったサービスを選ぶことが大切である。つまり、そのテストは何ができて、何ができないかを自身が把握することが必要になる。多くの顧客が「ベンダーにテストを実施させれば安全になる」と考えているが、提示されたテスト観点で見つからない脆弱性は報告されないのである（例えば、脆弱性診断を頼んでも特定ユーザの脆弱なパスワードは見つかりにくい）。セキュリティテストは可能な限りベンダーとその条件や環境について話し合い、双方納得の上で実施することが最良のサービス利用法といえる。